- Warmup Project and Gaining Familiarity with our Toolset: 20.77%
- Mobile Robotics Structured Project: 13.85%
- Computer Vision Structured Project: 6.92%
- Computer Vision Open-ended Project: 20.77%
- Open-ended Final Project: 27.69%
- Participation and Professionalism: 10%
Where the heck did these numbers come from?!? After factoring out participation and professionalism as 10%, the remaining 90% is divided up by how many class sessions you have to work on each of the assignments.
A portion of the grade for each project will be based on a writeup or other communication piece that you turn in. The rubric for these communication pieces will be defined on a per-project basis. I will be using a consistent rubric for assessing code though.
100%:
- Functionality: For assignments that have well-specified behavior, the code should be able to pass (or very nearly pass, e.g. there may be minor output formatting issues) automated unit testing of all required features. 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. For open-ended assignments 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: For assignments that have well-specified behavior, the code should implement all of the required functionality. For this grade, it is possible that 10-20% of the functionality may be broken. For open-ended assignments 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). For these types of assignments 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. For open-ended assignments 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.