General

Final project presentation

• All team members must be involved in the final project presentation. (Everyone should present something in the presentation.)
• Final project presentation slots were drawn (by lottery) in class Wednesday April 14.  See the presentation schedule.
• Each group will have a maximum of 10 minutes for their presentation.This will have to be a strict time limit, particularly on Monday and Wednesday, because we have four groups on each of those days.
• After the presentation, there will be a few minutes for questions.
• If you need video, let me know ASAP.
• Your presentation should be geared towards your fellow students.  You should provide an introduction to your project, and summarize the techniques used and the results of your project.

Final project demonstration

• If appropriate, you should schedule a final project demonstration with me ASAP.  The demonstration must occur before 6pm on Friday April 30.
• Generally speaking, hardware projects should definitely do a demonstration for me.  Software projects may or may not need to do a demonstration.  See the grading section for more details.

Project report

• Final project reports are due at 12:01am Monday May 3.  No late reports will be accepted.
• Your final project report should be similar to the research papers that we have been reading throughout the semester.  Here are some guidelines:
• There should be an abstract, succinctly describing the project/problem you worked on and the results.
• There should be an introduction, explaining the project in more detail and giving an overview of the rest of the report.
• There should be a brief related work section, identifying relevant references.
• After these things should come the body of your report.  You can structure this however you like.  It should contain multiple sections.
• There should be some conclusions or summary.  The exact form of this will depend on your project.  You might summarize experimental results and relate them to your premise (how well an algorithm/technique solves some problem).  You might suggest alternative solutions or reflect on better ways of approaching the problem.
• There should (in general) be a bibliography listing relevant works. You do not need to do an extensive literature search for your project.  For those of you implementing an algorithm from a paper, you might only need to list that one paper.  For some of the experimental projects, you might not need any references (however, if you referred to any other works in the robotics literature while working on the project, you should include them here).
• Your project report should be between 6 and 10 pages long (inclusive).  This includes everything: figures, tables, bibliography, examples, etc.  Note that I am not asking for code listings.  For experimental projects (hardware and software), you should give several experimental results or output.  For example, for a path planner implementation, you might include a figures of several different worlds (obstacle configurations) and possibly different start and goal configurations and the resulting paths.  You might also include run times.
• Here are some typographic parameters, just because I know otherwise, someone's going to push it:
• no smaller than 10 point type.  (bibliography can be 8 point if you want)
• no less than 1 inch margins (top, bottom, left, right)
• I don't have to explain to you, do I, that if you take a 10 page single sided report and xerox it, double sided, on to 5 sheets of paper that it's still a 10 page report?
• You can ask me about the mechanics of generating the project report. I can tell you about generating postscript output to create figures, among other things.  Don't think that you have to integrate everything electronically into the report.  It would be better to simply xerox a figure into a report than waste an hour trying to figure out how to convert a bitmap to encapsulated postscript and then include it in your document.
• If there is some reason that you think you should be allowed to exceed these length guidelines, ask me (by end of day Wednesday April 28). Otherwise, I reserve the right to simply ignore anything beyond the first10 pages.
• Also, see the grading criteria below.

Grading

• By default, all members of a team will receive the same grade for the final project.  If there is some reason that you think that this should not be so for your group, you should let me know.  You must do so by end of day Wednesday April 28.
• Your final project grade will be detemined 15% from the presentation, and 85% from the written report (and demonstration, if applicable).
• Last week, a student complained to me that since the final project grade is based solely on the presentation and written report, it doesn't matter what work you do on the project implementation.  My response is that I have to evaluate your project.  Although there is value in the experience of working on the project, I cannot evaluate this.  Even if I could, it is not clear that this is a fair criterion to use.  Instead, I will focus on results.  I do not admit to reading minds, nor do I want to look over everyone's shoulder while they are working on the project.  Therefore, you must communicate your results to me, and the way you can do this is through your project report (and possibly through a demonstration).
• This said, you should schedule a demonstration with me if it will convey your results in a way that the written report cannot.  (This is my rationale for saying that in general hardware projects should schedule a demonstration with me and software projects may or may not.)  See the deadline for doing a demo above.
• The basic criterion upon which I will evaluate your final project is how good a job did you do on what you proposed.  Here are some more specific criteria, based upon the type of project you are doing.
• For those of you implementing an algorithm from a paper, you should demonstrate an understanding of the algorithm by explaining it clearly and concisely in your project report.  You should describe your insights and experience from implementing it.  You should show the limits of the algorithm and/or the thoroughness/correctness of your implementation by showing an appropriate number of example runs.
• For those of you solving a problem from scratch (the yoyo, throwing arm, and maybe the maze groups), you should describe your problem precisely, present your analysis of the problem, describe your method of solution (and justify your choice, if appropriate), and characterize how well your solution/implementation works (through analytical limitations on your method and/or from experimental trials).

Let me know if there is any question regarding this information, and I will update this document as necessary.