last updated: 2016 May 25
Pre-Review Discussion (Weeks 4 or 5)
Overview
- 10-15 min discussion with at least 2 course instructor
- Teams are welcome to (and should!) talk to multiple instructors (a checklist will be kept in Hebb 42 to verify which groups have talked with instructors)
Expected
You will be able to discuss your ideas about the general robot function, including general details on the following:
- Mechanical – hand drawn sketches or early CAD models of major mechanical components.
- Electronics – Block-diagrams showing major connections, diagrams of wiring connections between PCBs and components.
- 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 minimize any risks with overall operation – convince us and yourself that your design will work.
- Risk Assessment – Identification of the biggest risks/obstacles for your design during fabrication and operation.
Outcome
With the help of TAs/instructors, identify the major problem areas to address for the Design Document.
Formal Design Document – Overview (Week 6)
The document will be assessed separately for the technical preparation 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 include in your document should be to explain material which cannot be explained using Figures or Tables.
Formal Design Document – 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
- Preface (1pg)
- Overview of Basic Strategy (1 pg)
- Chassis (1 pg)
- Drive System (1 pg)
- Sensor System (1 pg)
- Software Code and Algorithms (1 pg)
- Risk Assessment and Contingency Planning (2 pg)
- Major Milestones, Task List, and Team Responsibilities (1 pg)
- Document Contribution Summary (1 pg)
- References/Appendices (no limit)
Letter of Transmittal
The Letter of Transmittal is used to introduce group to the intended audience, establishes your credentials for the project, highlight special features of the proposal that the audience, 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 specific people, whereas the Proposal document 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
- 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.
Document Contribution Summary
Groups are requested to describe the contribution to each section by each person in the group. This is not for any marks distribution for this assignment, but only as a documentation tool. Groups may choose to redistribute work done for this document along with the rest of the course.
Using a table to format this section may help to keep the information together.
| Document Section |
Draft Writers |
Editors |
Comments |
| |
|
|
|
| |
|
|
|
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.