12.3.1 Timeline - Tentative

Sept 3 - Teams assigned

Sept 19 - Preliminary design concept submitted with specifications

materials list estimate

budget estimate

Gantt charts

Sept 21 - Design concept approved

Oct 17 - Proposal submitted

detailed drawings (CAD)

materials list

budget

calculations/simulations

Oct 19 - Proposals approved, mechanical building begins

Oct 26 - First mechanical test

Nov 2 - Second mechanical test

Nov 7 - First controlled test

Nov 14 - Second controlled test

Nov 16 - First draft of report posted to the web used to determine the score for competition

Nov 21 - EGR 345 competition and judging

Nov 30 - Final report draft posted to the web

Dec 10 - EGR 101 final project morning (EGR 345 students attend)

12.3.2 Teams

The teams are typically composed of up to 5 students from EGR 345. The EGR 345 teams are grouped using the self evaluation attached in the appendices.

 

Teams are expected to divided tasks for members to work in parallel. It is also expected that team members will review the work of others to ensure accuracy and completeness. This is particularly true of calculations, materials lists drawings and budgets.

 

All team members are expected to work in a professional manner. The general rules of conduct in a team are,

- treat others as you want to be treated

- communicate expectations and problems clearly

- be polite and accommodating

- when problems arise, help to solve them, even if they are not your fault. Don’t lay the blame for problems on others.

 

Personal conflicts must be resolved by team members in a professional manner. The performance of the team will be assessed using peer evaluations on a regular basis and may impact individual grades. In the case of non-participation the penalty may be up to 100% of the project grade.

 

In the event that team members cannot resolve differences with a team member, the team may ’fire’ the team member by a vote (it must be unanimous, except for the member in question). In this case the ’fired’ student is responsible for finding another team that will accept (or ’hire’) them. In the event they cannot find another team to join, they will be expected to perform all of the work themself. The firing mechanism is intended to deal with individuals who ’harm’ the progress of the team, not for non-participants.

 

12.3.3 Conceptual Design

Concepts are normally communicated with sketches that make the overall design clear. Components that would be expected for this type of design are,

- There should be a minimum of 3 conceptual designs, however more are recommended.

- A decision matrix should be used to justify the design selected.

- Sketches should be done using normal drafting practices. A good set of sketches will include 2-D, isometric and pictorial views.

- Calculations should be provided that support the design concept.

- Electrical schematics to describe the control system.

- Block diagram to describe the control system.

- Lists of components and budgets to indicate the major parts of the system.

- Other items, such as flowcharts, are often required to clarify the design concept.

12.3.4 Progress Reports

Teams are expected to submit progress reports on a weekly basis. These reports will include the following elements divided into sections with a heading for each. Point form is preferred, but complete sentences must be used. (Note: ’Parts purchased’ should be ’Parts were purchased for the cart assembly.’) Each section should include items completed since the last report, and current action items. If there is nothing to be said about a category use ’no changes’, ’nothing done’, or ’complete’ as appropriate.

 

Cover Page - a cover sheet indicating the course, project and team numbers. The names of all team members should be listed on the cover.

Gantt chart - updated on a weekly basis and included each time.

Budget - when changes are made, include an updated budget. The budget table should include descriptions, suppliers, quantity, price, and status.

Mass Table - when changes are made, include an updated mass table. Note: this can be combined with the budget.

Design - Design changes should be indicated. Appropriate drawings, schematics, or equivalent should be included. When appropriate, these should normally be accompanied by a new set of models, calculations and/or simulations to verify the new design.

Software - The current status of software development should be indicated, including major accomplishments and issues.

Fabrication - The status of items being built/assembled should be indicated.

Purchasing - The status of ordered items should be indicated.

Testing - The testing progress should be indicated, including any numerical results when available.

Other Issues - Items that may impact the success of the team should be indicated.

Performance - A prediction of performance, including the overall performance equation.

Early in the semester, other items will be requested, such as a combined timetable for all team members, and a skills inventory. These should only be included in the reports the weeks they are requested.

12.3.5 Design Proposal

The design proposal is used to present all of the design details in a single document. The focus of this document is a MINIMAL AMOUNT OF TEXT, but a thorough presentation of the design details. Typical elements are listed below in a typical sequence;

- a cover page indicating all of the team members and all other pertinent information.

- a table of contents

- three view drawings of each significant part

- block diagram of the control system (s)

- block diagrams showing the system architecture

- circuit schematic

- if a motion profile will be used, it should be documented

- an assembly drawing of the mechanism, including a BOM

- a budget listing each of the parts that must be purchased/acquired. Catalog pages and quotes can be used to validate the budget. In the final report, copies of receipts, or catalog pages will be required.

- a weight inventory, itemized by each part of the design

- additional calculations for mechanical design issues, such as stress that may result in failure. Normally these result in a factor of safety.

- the equations of motion for the system

- a Scilab program that verifies the operation of the system using the equations of motion.

- a prototype C program that implements the controller as designed.

12.3.6 The Final Report

The final design will follow the same structure as the Design Proposal, with the addition of the following elements.

- test results

- the drawings, calculations, etc. should be based upon the final design. It is reasonable to write a page or less about the modifications that were required, but it is a minimal/optional part of the report.

The report should concisely and clearly describe the design, as shown in the diagrams, drawings, calculations, etc. In general the format of the report is as outlined below. Sections and subsections should be numbered.

Cover page

Executive summary - one page or less that summarizes the design and results.

Table of contents

Design description - this section should describe the mechanical, electrical and software design aspects. Subsections should focus on the following elements;

Drawing summary - selected isometric and assembly drawings

System block diagrams

Description of control scheme, such as the motion profile

Schematics

Calculations - FBDs and differential equations

Project budget and BOM

Weight inventory

Test results - this section should describe

Simulation results

The tests that were done to describe the overall performance. There should be a comparison of the cart with and without sway compensation.

The results of formal tests should also be described.

A comparison of overall score estimates.

Conclusions - A brief description of the overall results indicating what the strengths and weaknesses of the design.

Recommendations - Suggestions for improvement.

 

Appendix - Drawings

Appendix - Stress and other similar calculations

Appendix - Controller C program

Appendix - Simulation program

Appendix - Receipts and cost evidence

Final reports will be evaluated on numerous factors including the clarity for the design documentation (i.e., how clear is what has been done?), theory to backup the design (does the theory match the actual design?), did the theory and actual match?

12.3.7 Gantt Charts

Gantt charts are used to track major project tasks, including sequencing. a brief tutorial on project management with Microsoft Project is available at http://www.stylusinc.net/ms_project_tutorial/project_management.shtml. You may also download (free for 30 days) project management software from http://www.smartworks.us/htm/downloads.htm. In general a Gantt chart should include,

- Most project parts should have a development, and then a review stage by another team member. For example, if one task is preparing mechanical drawings, this should be followed by a review task - done by another team member.

- Most tasks that stretch more than a week should be broken into smaller sub tasks.

- A Gantt chart should be presented on one single sheet. If it is small enough this can be one page, otherwise a larger sheet can be used.

- On a weekly basis a Gantt chart should be updated to include the completion of tasks.

12.3.8 Drawings

All drawings will observe the standards used in EGR 101 (see the EGR 101 or 345 course pages). This includes dimensions and tolerances that can be produced using the available equipment and materials. Please note that ’sketch’ means that it is done by hand, approximately, while drawing means it is done formally in a CAD package. Normally you should create solid models, and then generate multiview drawings. Note: All drawings must have a title block.

 

Shaded views have very little value and should be avoided, wireframe drawings are much more useful. If there is a definite need to include a shaded drawing, change the background to change the quantity of toner used.

12.3.9 Budgets and Bills of Material

Budgets should list all substantial components. Consumables, such as bolts are normally listed under a ’miscellaneous’ heading. However, all other components should be listed, and prices provided. If the components have been drawn from the engineering stores, similar devices can be identified from catalogs and those prices may be used. If your design calls for parts not commonly issued to engineering students, you may be required to purchase these yourself. An excellent local source of small parts is hobby stores, such as Ryder’s Hobbies on 28th St. The budget should also list the quantity of parts/material, price, source/supplier and status (eg., not ordered, received, due 2 weeks, late 1 week).

 

Don’t forget to include cost of the controller and other components used. Assume the power supply is provided as part of the crane system and therefore has no cost is associated. Some of the commonly available components are listed below. List simple commodity items such as wires, bolts, etc., under a miscellaneous category with a general cost estimate.

ATMega32 circuit board $30

Breakout board $20

motors assume $10

CT3001-ND 16 position, non-detent mechanical encoder $2.58

Potentiometer 10K (Digikey #296xd103b1n) $3.61 (???)

 

A Bill of Materials (BOM) lists all of the parts required to produce or assemble some other device. This is different from parts listed in a budget in that some of the parts will be work in process. In other words, the original material has been worked on to produce new parts. A BOM is normally found on assembly drawings.

 

Notes;

- there are different type of plastic, some are more brittle, others are tougher.

12.3.10 Calculations

Calculations are required to justify the design work. These should follow the conventions used in EGR 345. When computer programs are written, they should be commented and included.

12.3.11 Presentations

When doing presentations....

- avoid small fonts

- try to summarize the cost of the project

- give an overview of the project purpose

- use 1 to 1.5 slides per minute

- consider what the audience wants to know

- finely detailed mechanical drawings, schamtics, and equations can be difficult to see.

- don’t overload the audience with detail, if they want more they will ask questions.

- related visuals are good (i.e. pictures). Unrelated visuals are confusing.