CPSC 643-600: Motion Planning
(aka Robotics Programming)
Fall 1996

Project Assignment #3

Due: Friday December 13 by 5pm (see due date note below)
- worth 85% of project grade

This is the final assignment for your term project. What you need to turn in depends on the type of project you are doing. There are no page requirements - the papers should be as long as necessary (and no longer, please) for you to adequately address all the points mentioned below.

As with previous project assignments, your write-ups should be produced on a computer using some text processor, and you should check it for spelling and English. A portion of your project grade will be on presentation.

Survey Papers. What to turn in for a survey paper is the obvious - the paper. Components that your paper should include are:

  1. Introduction: a clear description of the problem/area which your paper is about and why it is interesting and/or important.
  2. Survey: discussion of the papers which you have read and generally what is the state-of-art for this problem/area. Your survey paper should not just be a collection of summaries of the various papers you've read -- it should give a good overview of the area. For example, you will probably want to organize your paper according to the problems/topics (rather than by the papers you've read).
  3. Open problems/directions for future research: based what you have learned from your survey, you should identify several as yet unsolved problems and/or issues that need futher study. For these, try to be as specific as possible, i.e., clearly define the problems. In addition, try to give any insight you might have as to how they might be solved, e.g., what techniques do you think might be useful, what are important subproblems, etc. Plan on spending some time on this part of the paper - I view it as one of the most important components.
  4. Bibliography: an annotated bibliography which includes the papers you've read, and also other papers related to the general problem/area you have studied. This bibliography should be comprehensive enough that someone else could familiarize themself with the field by only looking at these papers.

Work on Open Problems. If you are working on an open problem, then what you turn in will depend somewhat on your progress and whether or not there was an implementation component to your work. Write-ups should include:

  1. Introduction: a clear description of the problem and why it is interesting and/or important.
  2. Previous work: a description of what was known so far about this problem, i.e., what is the current state-of-the-art.
  3. Your work: a description of what you have done. If you have not been able to 'solve' the problem, describe the the things you tried, explain how they failed or where you got stuck, and describe any partial results you have. If you have been able to solve the problem, then explain your results in detail.
  4. Implementation results: if you implemented your ideas, then you should document your work as described in number 3 below for implementations. (If appropriate, you will also need to arrange to give me a demo, and I may ask you to turn in your code - so be sure it is adequately documented.)
  5. Conclusions: a description of the issues you think still need to be studied regarding this problem, and any insights you have obtained into what might be good/bad approaches or techniques to try.

Implementation Projects. If you are working on an implementation you will need to turn in a write-up describing the implementation and schedule an appointment with me to demo your project. I may also ask you to turn in your code electronically - make sure it is adequately documented. Your write-up should include:

  1. Introduction: a clear description of the problem and the goals of your implementation.
  2. Algorithm/method descriptions: explain what it is you implemented (give references to technical literature where appropriate). If you made changes/simplifications to already known algorithms, then be sure to specify them here.
  3. 'User manual': an explanation of the design/specification of the program and how it can be used. The description of the program should include at least the calling structure of major subroutines and their input/output specifications, including any format requirements. The 'usage' portion of the document should enable someone unfamiliar with your code (e.g., me) to use it without too much trouble.

REMARK ON DUE DATE: If you turn in your report (and, for implementation projects, hold your demo) by the due date of December 13 at 5pm, then you will receive your grade in the course on time.

If you are not able to finish by this date, you may have an extension until Friday January 17th at 5pm. In this case, you will initially recieve an 'I' (Incomplete) grade for the course which will be changed to the appropriate grade after you turn in your project. In order to receive this extension, you must consult with me prior to the original deadline of December 13 - failure to do this will result in a failing grade for the project and course.