Final Project

Checkoff

Groups have two options when getting their final project checked off:

  1. Full Project Functionality and Demonstration: Show that the project works correctly as a whole. This checkoff is graded as either a Sucessful or Unsuccessful test. If a Successful mark is awarded for this demonstration, full credit for the final project checkoff is awarded. If the full demonstration is deemed Unsuccessful, then the next option is required.

  2. Building Block Functionality and Demonstration: Show that the underlying pieces of the project work as individual components without full-project operation or demonstration required. Each building block is graded as an independent unit, regardless of other block operation. Students should be prepared to isolate each block (e.g., operate PWM module by itself, print values, view outputs, etc.) and discuss the implementation. See the checkoff sheet for rubric documentation.

Checkoff Sheet: Checkoff Sheet

Report

Groups are required to submit a report detailing their final project. It should be written assuming that the reader is aware of most aspects of the class content; that is, unnecessary descriptions of basic functionality (e.g., how GPIO pins work) should not be included. The report should contain the following sections:

  • Project Introduction and Description: Give a high-level overview of the project goals. If using the class provided problem (see lecture), simply state that problem with little description. If not using the class provided problem, make sure to describe the problem thoroughly. This description should match with the submitted “final project proposals” unless changed with the approval of the instructor.

  • Proposed and Final Solutions: Describe with a few sentences how the group solved, or attempted to solve, the problem. If groups made several different attempts to solve the problem, they should be noted here as well.

  • High-Level Design: Provide a high-level design description for the implemented solution. Groups should include a flowchart or state diagram visualizing the solution process in order to support the text description. This section should discuss the “Building Blocks” of the project, what their functionalities and purposes are and how they interact with the other Building Blocks.

  • Low-Level Design: Describe how each building block was designed/implemented. These descriptions should be supported by pseudocode, flowcharts, and/or lists/outlines with minimal paragraph formatted text used to introduce the material.

  • Verification of Operation: Provide proof of operation of many/most building blocks. This can be done via terminal outputs, oscilloscope plots, graphs (etc.) showing the input/outputs of the Building Blocks. For simplistic driving schemes, a terminal log of a successful (or unsuccessful) attempt at solving the problem is acceptable. For example:

    • If using a light sensor, a graph could be provided showing the light sensor response to a moving light source.

    • If using bumpers for navigation, a verbose terminal log of the program’s operation would suffice.

    Ensure that all material provided in this section has apt descriptions aiding in interpretation. It is not necessary to verify basic functionality. For example, there is no need to document the successful implementation of a simple GPIO output; however, if a custom PWM output is used, a figure showing the correct period and pulse width generated would be useful.

  • Conclusion: Discuss what worked in the project, what didn’t, and what could be improved. Note any unexpected behaviors encountered, and how they were compensated for (if applicable). If the project was ultimately unsuccessful as a whole, ensure to thoroughly discuss the group’s understanding as to why is did not work.

There is no length requirement for the report. The report should be a length that allows for the succinct documentation of all sections above. Excessive “Fluff” text which is added to unnecessarily increase the length of the report may incur a penalty.