Course Policies

Evaluation

Your grade in this course will be based on the following assignments:

Warmup Project: 10%

Mobile Robotics Project: 20%

Computer Vision Project: 20%

Open-ended Project: 30%

Participation and Professionalism: 10%

Other Out of Class Assignments: 10%

I will grade each of these assignments based on a combination of code quality, writeup quality, and presentation quality (if applicable). The breakdown between these three components will be specified in each assignment description. Note that some assignments in the "other out of class assignments category" will simply be recorded as a check if you did it and a 0 if not.

The grading rubric for code quality is:

100%:

    • Functionality: For open-ended assignments the code must be easy to run without modification and implement all of the required functionality.
    • Documentation: all functions are commented with appropriate doc strings. There is a README file discussing how to run the program and what it is supposed to do.
    • Style: the program exhibits effective modular design. The code does not have unnecessary cut and paste code or magic numbers. Variable and function names are sensibly chosen.

80%:

    • Functionality: It will be possible to get the code running with modest effort (i.e. it will not be as well documented as in a 5, but it isn’t too hard to intuit how the code works). All required features must be present, however, some (10-20%) may not be functioning properly or otherwise poorly implemented.
    • Documentation: some functions are missing doc strings. Comments are fairly minimal.
    • Style: some aspects of the design of the program could be improved to reduce cut and paste code. Variable and function names are for the most part well-chosen.

60%:

    • Functionality: The code should implement almost all of the required features (it is okay if roughly 20% are not implemented). A significant portion, 30-50%, of the code may not work as it is supposed to.
    • Documentation: Docstrings are mostly absent For well-defined assignments the code does not run as it should based on the assignment spec. There may not be any indication of how to run the program, and it is not easy for a NINJA to figure out how the code works (a good test is if you have to e-mail someone to ask them how their code runs, they are probably at this level).
    • Style: the program design needs improvement. The code would be a lot cleaner if the author had done a better job thinking through the appropriate functional decomposition. The code has lots of cut and paste and magic numbers. Variable and function names are hard to interpret.

40%:

    • Functionality: the assignment is incomplete (~50% of the functionality is not implemented). The functionality that is implemented is not 100% correct.
    • Documentation: documentation mostly absent.
    • Style: design is poor. Very little attention has been paid to choosing a sensible functional decomposition. Variable and function names are chosen almost arbitrarily.

20%:

    • Functionality: only minimal functionality is present.
    • Documentation: little or no documentation.
    • Style: no comments or docstrings. Code is not “readable”. Poor choice of variable and function names.

0%: nothing turned in.

The "presentation quality" and "writeup quality" rubric will vary depending on the specifics of the assignment (see each individual assignment page for details).

Late Policy

Most of the projects will culminate with an in-class demo / presentation. I will be assessing the code that is checked into your GitHub repository on the day of the presentations. No exceptions will be made. For assignments that do not culminate with a presentation, I will accept assignments up to 5 days late with a 20% per day late penalty.