last updated: 2014 May 26.

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. 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 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 APSC 203 and ENPH 253.

For ENPH 253, the most successful design documents are the ones which provide documentation used to help execute on robot fabrication and testing – avoid filler material.

It is highly recommended that you start organizing your document with a list 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.

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 TransmittalTitle PageAbstract1 pgGlossaryTable of ContentsList of Illustrations Introduction and Overview of Basic Strategy1 pgChassis1 pgDrive System1 pgSensor Systems2 pgElectrical Design2 pgSoftware code and Algorithms2 pgRisk Assessment and Contingency Planning2 pgMajor Milestones, Task List, and Team Responsibilities2 pg AppendicesReferences

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.

Abstract

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.

Glossary

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.

Chassis

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.

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 fastening each component (screws, spot welding)

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.

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)

Sensors and Feedback

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:

TINAH Resources (Digital/Analog/Motor control specification) – table should showing all 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

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

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.

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 what 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. Find descriptions for how to draw state diagrams.

Error handling algorithms:

algorithm when tape is lost

algorithm for deciding between tape tracks

algorithm for doing 180 degree turn on tape

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.

Risk Condition	Probability of occurrance	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, How tasks are divided among all 3 or 4 group members

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

UBC Engineering Physics Project Lab

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

Design Proposals and Reports (2014)