Undergraduate Project Instructions

7/29/2019 Undergraduate Project Instructions

http://slidepdf.com/reader/full/undergraduate-project-instructions 1/9

GUIDELINES FOR UNDERGRADUATE PROJECT

Engineering design is the creative process of identifying needs and then devising a product or a process to fill those needs. After a need has been identified, the purpose of an engineering design project proposal is to succinctly communicate to interested parties:

Benefits of the product or process to the end customer

Project objectives tied to the project specifications

Strategy for achieving project objectives

Detailed plan of action divided into a number of tasks to be performed by

individual members of the design team to achieve the project objectives

Time schedule depicting weekly progress and individual/team assignments

Cost analysis

Design verification procedures

Procedures to quantify prototype performance

Ideally, undergraduate research should focus on a well-defined project that stands a reasonablechance of completion in the time available. A literature survey alone is not a satisfactory research project. Neither is repetition of established procedures. The objectives therefore of EEE 199 are:

1. Applying and integrating the classroom material from several courses;2. Introducing the professional literature;3. Gaining experience in writing a technical document, and4. Enhancing employability through the evidence of independent work.

1.0 PROPOSAL FORMAT

See the attached format for the EEE 199 Project Proposal. Times New Roman size 12 fonts.I. Title Page (center justified, right-left, top-bottom)

Title – All capital letters, font size 16-20Proposal for ECSE-xxxx Senior Design Project Names of team members (one per line, font size 16)DateRensselaer Polytechnic InstituteYou may choose to add a team logo on top of the title. Use multiple spacing betweenvarious items for a good visual effect.

II. Body of the Proposal

IntroductionWhat is the project about and what is your/sponsor‟s motivation to select/sponsor the project? Review any prior work in the subject area. What is the state of theart? Who are the expected end users? Describe in detail customer requirements, preliminary specifications, related technology areas, competitive benchmarks, andany related patents. Comment on the scope of effort involved in general terms.

ObjectivesDescribe the project goals and intended functions and features. Carefully statehow you have narrowed or broadened the scope of the project based on availabletime and labor resource. Comment on critical design parameters and whatchallenges might stand in the way of accomplishing your design objectives. Be

ever alert to professional and societal context of the design objectives as it relatesto engineering standards, and realistic constraints that include one or moreconsiderations of economics, environment, sustainability, manufacturing, ethics,health and safety, and social and political impact. Make sure your objectives areclear. Clear objectives lead to a clear plan for generating the tasks to accomplishthe design goals.

Design Strategy



If the deliverable at the end of the semester is a product - a piece of hardware or software, or a combination of the two, use a general block diagram (super block)to convey your design strategy. Each block in the super block must be as modular as possible, so that it can be implemented independently and re-assembled later.Describe the function of each block briefly and explain how it contributes to the

overall design and feature list above. Include a discussion on the interface withother blocks of your super block, and with super blocks designed by other teams,as applicable.If, on the other hand, your project were exploratory in nature because, for example, the technology needed for product development is not mature, or morethan a semester is needed to finish the project, then your strategy would have to be modified accordingly. Your strategy would be to generate information to beused by another team working on the same project in the following semester. A block diagram format for design strategy presentation may, or may not besuitable. This must be decided on case-by-case basis.

Plan of Action

The plan of action consists of various tasks needed to implement the designstrategy. The tasks should be linked to the objectives and the design strategycomponents. The tasks should be explicitly divided among the team members for a well-rounded experience for all. To be specific, one person doing all theanalysis, another simulation, and another implementation, and yet another testing,does not lead to a well-rounded experience. All must share these activities,though not necessarily in exactly the same proportion.

VerificationTesting Procedures: Outline the test procedures and resulting tables, graphs, andmeasured values that will assess the project performance. Separate test procedures should be given for testing individual modules and integrated

subsystems, and the overall system.Tolerance Analysis: As part of your project, describe one engineering componentor subsystem that most affects the performance of the project. Later on you willtest this component at extremes and include the result in your notebook and finalreport, along with any insights you have gained while performing the analysis.

Cost and ScheduleCost Analysis: Include a cost estimate of the project based on labor and material.Include a list of parts, lab equipment, and/or shop service, as appropriate. Givethe estimated cost of any such items. Compute labor cost for each team member on the project as follows:Assumed dream salary ($/hour) * 2.5 * hours spent = $Total

Itemize total labor cost for all partners, all material cost and cost of specializedlab equipment and shop service and determine the grand total for the project.Schedule: Include a timetable showing when each step in the expected sequenceof design and fabrication work will be completed (generally, by week), and howthe tasks will be shared among the team members. (i.e. Select architecture,Design this, Design that, Buy parts, Assemble this, Assemble that, Prepare mockup,Integrate prototype, Refine prototype, Test integrated system). NOTE: The actual costs and schedule will be part of your Final Report. Keep arunning log of cost and schedule in your notebook.

References ConsultedA list of books, papers, and websites relevant to the project.

GUIDELINES FOR UNDERGRADUATE DOCUMENTATION

I. ORGANIZATION OF THE FINAL PROJECT DOCUMENTATION

Your project documentation should be written with sufficient details and explanations that a newstudent can read it and continue your work. A typical documentation chapter is between 10-30



pages long including figures. With the exception of the Introduction chapter, every chapter should begin with an Introduction section and end with a Conclusions section.

Although the organization of every undergraduate project/ research documentation is slightlydifferent, the typical documentation consists of the following chapters:

Chapter 1. Introduction

This chapter is relatively short, usually between five and 10 pages. It should present some background about the research area, the motivations for the project, the projectobjectives, the scope and limitations, and a brief overview of the plan of action. It endswith a brief description of the contents of the remaining chapters.

Chapter 2. Literature Review

This chapter should present a critical review of the relevant published literature. It

normally consists of several sections related to your research objectives (i.e. the ones presented in Chapter 1).

Chapter 3. Methodology

This chapter includes details about the experimental procedure(s), the designspecifications and implementation details. This should include block diagrams,algorithms, and circuit components to use. Also, the testing strategies should be presented, along with the schedule of implementation (Gantt Chart) and cost analysis.

This section should describe what was actually done. It is a succinct exposition of the laboratorynotebook, describing procedures, techniques, instrumentation, special precautions, and so on. It

should be sufficiently detailed that other experienced researchers would be able to repeat thework and obtain comparable results.

If the experimental section is lengthy and detailed, as in synthetic work, it can be placed at theend of the report or as an appendix so that it does not interrupt the conceptual flow of the report.Its placement will depend on the nature of the project and the discretion of the writer.

Chapter 4. Results and Discussion

This chapter presents in detail all of the experimental procedures actually implemented inthe conduct of the study as well as an analysis of all test results. In this section, relevant

data, observations, and findings are summarized. Tabulation of data, equations, charts,and figures can be used effectively to present results clearly and concisely.

The crux of the report is the analysis and interpretation of the results. Specifically, for each test/ procedure, the following questions should be answered:

1. What is the purpose/ objective of the test/ procedure?2. What are the mechanics of the test or the procedure for testing?3. What are the quantities to be measured? What are the specific inputs andoutputs?4. What are the expected results? Compare this with actual results (plot or tabulate).

5. What do these results mean? How do they relate to the objectives of the project? Interpret and discuss the significance.6. To what extent have you resolved the problem? Discuss all the errors/ problemsencountered during the test and how they were resolved (present troubleshootingtechniques).

Chapter 5. Summary, Conclusions and Recommendations



This chapter is mainly a concise statement/s of the conclusions given in earlier chapters.

The last section should present recommendations (and basis thereof) for continuations of your research.

References

References should be numbered in the order they appear in the documentation. See notes

on References .

Appendices

Items such as long calculations, raw data, part drawings, specifications and schematicdiagrams, codes, etc. should be placed in the appendices.

General points:A. ON CODES AND PROGRAMS

1. Back up your files – code, data files, and documentation - frequently.

2. Keep and organize all your data files. Subdirectories can help with this. Create a “readme.txt” in each subdirectory containing details of the contents of all the files in that subdirectory.

3. At the top of each program you write, include a dictionary of variables. For example, if writing code in MatLab:

% Dictionary of Variables:

% A[] Array of coefficients for the polynomial A(z-1

) … % thB Base angle of the robot…

4. Add comments to the rest of your program so it can be understood by someone else ( your adviser or those who will continue your project…)

5. Make a separate file for every figure, drawing or picture, whenever possible. For example, if you use MatLab to create graphs, save each as a . fig file. Use descriptive names (e.g. general_blk_diagram.jpg ) and create a “readme.txt ” file as in item 2.

B. ON THE DOCUMENTATION PROPER

2. Define acronyms once, when first used.

3. Define technical terms once, when first used. Also, be careful to use the same term or symbol

representation throughout the project documentation, e.g. do use „three-phase‟ and then „3-f‟ or

„3- phase‟ in another section or chapter. Be consistent.

4. Always include page numbers.

5. Keep all draft versions of your project documentation until you graduate so that you can keeptrack of your progress.

6. Refer to your figures in the text of your project documentation.



7. Include reference numbers and all authors‟ surnames for all work that is not your own. You

should use the first author‟s surname followed by “et al .” only if the paper has more than threeauthors. ( see sample References)

8. Define all symbols and units. Use SI units always.

9. If a standard term or symbol exists for what you are describing (e.g. AC for alternatingcurrent), then use it.

C. ON FIGURES, TABLES and EQUATIONS

1. Use equations, figures and step-by-step algorithms instead of just words whenever possible.Use Equation Editor or MathType for all equations. Do not copy-paste equations as figures.

2. Number all equations, figures and tables by including the chapter number and the figurenumber, e.g Figure 1.1 (if the figure is in Chapter 1 and it is figure #1).

3. Refer to equations, figures and tables in the documentation by their numbers, e.g. “as shown in

Figure 4.2…”

4. Results should be presented as graphs or tables.

5. Make sure your figures are not too small, the minimum size should be about 100mm by 100mm. When you resize, make sure you keep/lock the aspect ratio.

5. Put the figure on the same page as the paragraph the refers to it whenever possible. A goodrule of thumb is to put no more than two figures per page.

D. ON THE LITERATURE REVIEW

1. Point out the disadvantages AND disadvantages (or limitations) or prior work of others, and of your own work.

2. Refer to prior studies in the past tense, e.g. “they used ” and not “they use”.

3. Use quantitative (and not qualitative) descriptions whenever possible, e.g. “the accuracy is

±2mm” AND NOT “the accuracy is good”. Comparisons are also desirable, e.g. “the adaptive

algorithm improved the tracking error by 25% in comparison with the PID controller.” This

applies to your entire document, including literature review.

4. Use unique names for your variables and constants. For example, do not use V C to refer to avoltage in one chapter and to refer to a velocity in another chapter.

5. Do not create paragraphs that are too short. A paragraph should be normally at least three (3)sentences long. Only start a new paragraph when discussing a new topic.

6. Try to keep your writing concise. Shorter sentences are preferred because they are easier toread.

7. Be careful with significant digits (also called “ significant figures”). A measurement should bereported only with the digits you exactly know. If you are reporting the final result of acalculation, it should be reported with the minimum of the number of significant digits of themeasurements used in the calculation. If the accuracy of the measurements is unknown, or youare reporting theoretical values, a “rule of thumb” is to use 3 significant digits, e.g 4.92 mm/s.



8. In the literature review, it is good to group closely related work together (even if people arefrom different universities), for example: “Cruz’s group at MSU -IIT [8-10] have…” Other

examples are:“ Brown [7] determined that…” “Smith and Jones [1] and Roberts and Chang [2] produced similar findings.”

Or if several papers involve microcontroller-based design ( for example) then group themtogether. Subsections are also helpful in this chapter.

9. A literature review should not simply be a catalog or summary of previous work. For each paper or article, you should point out what specifically was accomplished, what the contributionsof the work are, and what the limitations of the work are. For example, if no experimental resultswere given in the paper, then state this in your documentation. Also, provide numerical resultsrather than words like “ good ” or “excellent ”. If the authors‟ do not state numerical results, thenget them yourself from their graphs.

10. Do not use websites (e.g. Wikipedia) unless no other source is available. Usually websitescopy information from books or older papers. You should refer to the original source for theinformation.

11. For formatting of references: use the IEEE style (see sample Reference).

E. ON REFERENCES

1. References must be numbered in the order in which they appear in the text.

2. Once you label the source, use the same number in all subsequent references.

3. Each reference number should be enclosed by square brackets on the text line, with a space before the bracket, and before the punctuation: “… end of the line for my research [12].”

4. It is not necessary to mention the author(s) of the reference unless it is relevant to your text.Do not mention the date of the reference in the text.

5. It is not necessary to say “in reference [27]…” “ In [27]….” is sufficient.

6. To cite more than one source at a time:

[1], [3], [5] or [1] – [5]

.7. The names of all authors should be given in the references unless the number of authors isgreater than six. If there are more than six authors, you may use et al. (no comma before et ) after the name of the first author.

8. The reference list must be listed in the order they were cited (numerical order). The referencesmust not be in alphabetical order.

9. The bracketed number should be on the line, and the lines of each entry indented.

10. List only one reference per bracketed number.

11. Footnotes and other words and phrases not part of the reference format should not beincluded in the reference list. Phrases such as “for example” should only be given in the text.

12. Every (important) word in the title of a book must be capitalized.



13. Every (important) word in the title of a journal or conference must be capitalized.

14. Capitalize only the first word of an article title (except for proper nouns, acronyms, etc.)

15. Capitalize only the first word of a paper, thesis, or book chapter.

16. Ca pitalize the “v” in volume for a book title but not for a periodical.

17. Punctuation goes inside the quotation marks.

18. You must either spell out the entire name of each periodical you reference or use acceptedabbreviations. You must consistently do one or the other.

19. You may spell words such as volume, December, etc., but you must either spell out all suchoccurrences or abbreviate all.

20. You do not need to abbreviate March, May, June, and July.

21. To indicate a page range: pp. 111-222. But to reference one page only, use only one p : p.111.



References

BOOKS

[1] S. M. Hemmingsen, Soft Science. Saskatoon: University of Saskatchewan Press, 1997.

[2] A. Rezi and M. Allam, “Techniques in array processing by means of transformations,” in

Control and Dynamic Systems, Vol. 69, Multidimensional Systems, C. T. Leondes; Ed.San Diego: Academic Press, 1995, pp. 133-180.

[3] D. Sarunyagate, Ed., Lasers. New York: McGraw-Hill, 1996.

PERIODICALS

[4] G. Liu, K. Y. Lee, and H. F. Jordan, “TDM and TWDM de Bruijn networks and

shufflenets for optical communications,” IEEE Transactions on Computers, vol. 46, pp.

695-701, June 1997.[5] J. R. Beveridge and E. M. Reisman, “How easy is matching 2D line models using local

search?” IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 19, pp.564-579, June 1997.

ARTICLES FROM PUBL ISHED CONFERENCE PROCEEDINGS

The word in before the conference title is not italicized.

[6] N. Osifchin and G. Vau, “Power considerations for the modernization of

telecommunications in Central and Eastern European and former Soviet Union(CEE/FSU) countries,” in Second International Telecommunications Energy Special

Conference, 1997, pp. 9-16.

[7] S. Al Kuran, “The prospects for GaAs MOSFET technology in dc-ac voltageconversion,” in Proceedings of the Fourth Annual Portable Design Conference, 1997, pp.137-142.

PAPERS PRESENTED AT CONFERENCES, BUT UNPUBL ISHED

[8] H. A. Nimr, “Defuzzification of the outputs of fuzzy controllers,” presented at 5th

International Conference on Fuzzy Systems, Cairo, Egypt, 1996.

REPORTS (technical reports, internal reports, memoranda)

Provide number and month if available.

[9] K. E. Elliot and C. M. Greene, “A local adaptive protocol,” Argonne National

Laboratory, Argonne, France, Tech. Rep. 916-1010-BB, 1997.

THESIS or DISSERTATION

“Ph.D. dissertation,” but “M.S. thesis.”

[1] H. Zhang, “Delay-insensitive networks.” M.S. thesis, University of Waterloo, Waterloo,

ON, Canada, 1997.

MANUAL

[2] Bell Telephone Laboratories Technical Staff, Transmission System for Communications,

Bell Telephone Laboratories, 1995.

CLASS NOTES



[3] “Signal integrity and interconnects for high-speed applications,” class notes for ECE 497-JS, Department of Electrical and Computer Engineering, University of Illinois at Urbana-Champaign, Winter 1997.

PRIVATE COMMUNICATION

[4] T. I. Wein (private communication), 1997.

FROM THE INTERNET

[5] Computational, Optical, and Discharge Physics Group, University of Illinois at Urbana-Champaign," Hybrid plasma equipment model: Inductively coupled plasma reactive ionetching reactors,” December 1995, http://uigelz.ece.uiuc.edu/Projects/HPEM-ICP/index.html

[6] D. Poelman ([email protected]), “Re: Question on transformerless power supply,”

Usenet post to sci.electronics.design, July 4, 1997.

CATALOG

Catalog No. MWM-1, Microwave Components, M. W. Microwave Corp., Brooklyn, NY.

APPLICATION NOTES

[7] Hewlett-Packard, Appl. Note 935, pp. 25-29.

PATENTS

[8] K. Kimura and A. Lipeless, “Fuzzy Controller Component,” U.S. Patent 14,860,040,

December 14, 1996.

http://uigelz.ece.uiuc.edu/Projects/HPEM-ICP/index.html



mailto:[email protected]






Documents

Undergraduate Project Instructions