Skip to content

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

    Design Proposals and Reports (2013)

    last updated:  2013 May 28.



    Pre-Review Discussion (10-15min)


    • 10-15min discussion with at least 2 course instructors.
    • Any time during weeks 3, 4, or 5.
    • Teams are welcome to  (and should!) talk to multiple instructors beyond the required minimum, to review your ideas as you work on them in preparation for the Formal Proposal
    • 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



    • Overall   Verbal overview of general robot function
    • Mechanical   Printed / hand drawn version of major mechanical components and method of mounting key components together.
    • Electronics     Block-diagram of overall system showing major connections and block diagrams of wiring connections between PCBs and components.  Electronic schematics for individual PCB’s.
    • 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 dicussion, and in preparation for the Formal Design Document.
    • You should emphasize the application of appropriate engineering theory to your design.   Show calculations and estimates wherever applicable.



    With the help of TAs/instructors, identify the major problem areas to address for the Deesign Document, including:

    • Areas on the robot with the highest probability of issues (mechanical alignment, robustnes, repeatability, etc…)
    • Motor control and sensitivity issues
    • Electronics difficulties
    • Sensor difficulty
    • Difficulty in programming and algorithm development






    Formal Design Proposal  – Overview


    Material Covered

    • Printed document, ~10-25 pages
    • Material from the design document can be used in the final report to be handed in at the conclusion of the course.
    • The document will be assessed separately for both APSC 203 and ENPH 253.   For ENPH 253, the most successful design documents are the ones which provide documentation that is actually useful during the build phase.


    Key elements to the Formal Design Document

    • Calculations      What is the speed of each mechanism? What is its estimated time to travel the course?  How many objects do you expect to handle in 2 minutes?
    • Estimates      Estimate any quantities that you can’t measure easily.   This can include estimating various masses, required forces.
    • Testing procedure      Once part of your robot is constructed, how do you verify whether it works adequately or not?  Can you identify options during the design stage?


    Comments from Formal Design Proposals from Previous Years:

    • Testing:   When you claim to be “testing” something, think specifically about how to test and obtain unambiguous, conclusive, repeatable results
      • 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
    • Mech 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 amount of material? (for weight, for wasted material)
    • Electronics
      • Design and build to allow for easy transfer to a new/improved robot chassis.
      • Think about inputs and outputs on each board and how connectors will attach to each setup.
      • TINAH board should only source ~500 mA total on the 5V lines  (this includes the RC servo motor)!
        • Need more 5V power?  Use an external 5V regulator (7805)
      • Most groups are missing the following:
        • small batteries (for +/- power to OpAmps)
        • Power switches
        • Wiring harnesses (wire bundles/colours)
        • Easy method of swapping out primary battery pack.




    Formal Design Proposal  – Specific Sections


    Suggested Size for Proposal  Sections

    Suggested maximum length for written text

    (does not include calculations, figures, charts, tables)

    Letter of Transmittal
    Title Page
    Abstract 1 pg
    Table of Contents
    List of Illustrations
    Introduction and Overview of Basic Strategy 1 pg
    Chassis 1 pg
    Drive System 1 pg
    Sensor Systems 2 pg
    Electrical Design 2 pg
    Software code and Algorithms 2 pg
    Risk Assessment and Contingency Planning 2 pg
    Major Milestones, Task List, and Team Responsibilities 2 pg

    Suggested Max:  ~14 pages of written text (excluding Calculations, Figures, Charts, Tables and Appendices)


    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 not bound into the proposal since it is always written to an individual person, whereas the Design Document may be read by several people in order to be evaluated.




    The Abstract 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 Abstract:

    • 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.




    The Glossary should define any jargon or terms that a lay reader should know prior to reading the document.


    Table of Contents

    List of Illustrations

    For the Table of Contents and List of Illustrations:

    • All figures and tables should be given a descriptive title which can be used as a stand-alone description of the image or information.
    • When preparing the document, it is often most useful to generate a list of all figures and tables BEFORE any body text is generated.   Generating this list is useful for prioritizing what information should be included and in what order, and in planning the level of testing and analysis at each stage.



    Introduction and Overview of Basic Strategy

    The Introduction should describe  the context of the report, the expected audience, and what the reader should expect to cover in each of the following sections.   The section should also have a brief overview of the basic strategy for the robot, highlighting any key features of the robot to accomplish the tasks for the competition.


    The Chassis section should include information on the topics listed below.  It is recommended that this section make ample use  of figures and tables to describe this information, with the text used to explain and highlight specific components or specific techniques used by the team.

    1. Listing of each chassis component
    2. 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)
    3. Method of fabricating each component
    4. Method of fastening each component (screws, spot welding)
    5. 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)
    6. Ease of assembly/dissassembly  (TINAH, battery, fasteners)
    7. Ease of redesign of major components (leave room for modification)
    8. Estimated mass of system and components.

    Drive and Actuator System

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

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

    Sensor System

    The Sensor System section should include information on the topics 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:

    1. TINAH Resources (Digital/Analog/Motor control specification) – table should showing all pins and expected I/O
    2. Tape sensors
    3. IR sensors
    4. Collision detectors / Edge-of-surface detectors / Object detection
    5. Sensors for position feedback for different internal components


    Electrical Design

    The Electrical Design section should include information on the topics listed below.

    1. List of individual PCBs used in design (each PCB is named and/or numbered)
      1. Name of PCB
      2. Approx size
      3. Number and type of wiring connections to other boards/TINAH.
    2. Table of Physical Wiring Cables
      1. 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.
      2. Try to 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.


    Software Code and Algorithm

    The Software Code and Algorithm section should include information on the topics listed below.

    1. Overview of functions and control loops used for the robot.
      1. Flowchart or State Diagrams of individual functions of code
      2. Flowcharts – groups often do a poor job of drawing flowcharts.   Find resources online to explain what rules to follow for a proper sensible flowchart.
      3. 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.   Find descriptions for how to draw state diagrams.
    2. Error handling algorithms:
      1. algorithm when tape is lost
      2. algorithm for deciding between tape tracks
      3. algorithm for doing 180 degree turn on tape
      4. 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:

      1. the inability to detect IR in the range from 1foot to 7 feet using one circuit
      2. the inability to manipulate/recover  objects as required by your design
      3. 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.

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




    Task List, Major Milestones, Team Responsibilties

    Use this section to describe your task list, How tasks are divided among all 3 or 4 group members

    1. Task List
      1. Think of what tasks need to be completed.   Be as specific as you can!
      2. Think carefully about what order the tasks need to be arranged (which circuit is the first one that needs to be completed? what software needs to be written first?)
      3. Think of how to test and verify each stages of your robot
      4. Put the tasks into some sensible order, and see if you can place tasks concurrently as much as you can.
      5. Use whatever tool is appropriate to organize your tasks.  Gantt Charts can be a useful documentation tool, but as a planning tool it often makes it difficult to organizing the order of tasks.
    2. Major Milestones (for the 253 Major Milestone Day)
      1. 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:
        1. Chassis, drive motors and wheels mounted
        2. Power circuits complete
        3. Chassis following tape
        4. Pickup mechanism completed
        5. Software can be triggered to perform based on manipulating sensor
    3. Team Responsibilities
      1. You may choose to identify specific people for each of the Tasks.
      2. 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”)
      3. 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

    • 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.
    • We can publish your info on UBC cIRcle        If your team is interested in having any of your work (written reports, videos and webpages are fine) posted online and linked to the the UBC cIRcle repository, please include the following statement along with your report.   The repository has several Project Lab reports posted online, some of which have had good viewership!
    • 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.