Skip to main content Link Menu Expand (external link) Document Search Copy Copied
CSCI 1600, Fall 2026

Project

Table of contents

  1. Project overview
  2. Timeline
  3. Proposal (Due Friday, Oct 16 at 11pm)
  4. Progress milestone (Due Nov 13 at 11pm)
  5. Milestone report
  6. Overview slide
  7. Hardware demo video
  8. Final deliverables

Project overview

Design and implement an embedded project using one or more Arduinos and some external electronic components.

Your project must:

  • Use PWM, ADC, or DAC
  • Have a watchdog timer
  • Have at least one interrupt service routine (watchdog timer doesn’t count)

It must also use at least one of:

  • Serial communication
  • WiFi
  • Bluetooth
  • Timer/Counter (other than WDT. Arduino delay doesn’t count)

The scope of the project must be complex enough to demonstrate design skills and creativity but realistic enough to culminate in a functioning deliverable (feedback for this will be given during the proposal and milestone).

To be updated as we cover these topics in class The final writeup and demonstration will also feature documentation of process (requirements writing, testing plan, modeling)

Timeline

  • Thursday, Oct 8: Project groups assigned

  • Friday, Oct 16: Proposal due

  • Week of Oct 19: Proposal feedback received, parts ordering begins

  • Friday Nov 13: Milestone artifacts and demo video due

  • Week of Nov 16: Peer reviews (in class)

  • Reading period (date TBD): Final demo; deliverables due

Proposal (Due Friday, Oct 16 at 11pm)

Write a project proposal (about 1 page) that has the following sections:

  1. High-level overview of what the project will be.

  2. Explanation of how the project will fulfill the requirements above.

  3. Proposed final deliverable for the project: what physical object will you demo, and what is the criteria by which we will know that the demo is successful?

  4. For each sensor/actuator you plan to use, a short (1-2 sentence) description of how you will know that the component is working. Before building the final project, you should get to know your hardware, and this section should explain how you will do that. For example, if you’re ordering a stepper motor, a valid answer would be “getting the stepper motor to rotate by 1/8 turn, pause, and repeat until it goes all the way around.” If you can, include a link to the Arduino library (e.g. Stepper) that pertains to the component.

  5. Discussion of uncertainties, such as challenges you anticipate in implementing the project, timeline considerations, faulty components, etc. You don’t have to provide a contingency plan for each uncertainty, but you should offer some idea of what a scaled-back project would look like.

  6. Preliminary list of parts to be ordered, with links. For complex components, include a PDF of the datasheet with the Gradescope submission, if possible (to make Milda’s life easier). We will give initial feedback for this before ordering parts. The course is providing each group a budget of about $25-$30 for parts ordered with us through this process (you are welcome to use your own parts, especially if you have some lying around! Milda also has a selection of parts from previous years).

  7. Any resources (tutorials, libraries, videos) you’ve consulted in writing this report.

We’re aiming for parts orders to be placed by October 22. Factor in about a week of processing and shipping time to receive the hardware.

Progress milestone (Due Nov 13 at 11pm)

For the project milestone, you will turn in a short video demoing your progress on getting your sensors/actuators to interface with the Arduino. You will also produce a report that is composed of artifacts from the left/design side of the software engineering V-model. The state machine you produce will be peer-reviwed by other groups in the course.

Milestone report

Your report should have the following sections:

  1. Clear, concise, complete, and confirmable system-level requirements for your project, written with “shall/should” language as defined in class.

  2. An architecture diagram of the modules/components of the system and the interfaces between them. This should fit on one page and be a “boxes and arrows” diagram, as described in class.

  3. One sequence diagram that describes how the modules of the system will interact for one of the primary use case scenarios of the system, as described in class. For the progress milestone, you only need to provide one sequence diagram, but for the final report you will be asked to create three diagrams. Include a short (1-2 sentence) description of what the use case scenario is.

  4. One state machine that describes the detailed design of the main control module of your system, as described in class. You should clearly define the inputs, outputs, and state variables of the system. Remember to indicate how the variables are initialized and what the start state is. Also remember to number your states and give each one a concise name. Once you start coding your project, you will be expected to write your code according to your SM, like in lab 5 – figuring out the way your FSM interacts with inputs/other modules is a non-trivial design problem that you should start thinking about now.

  5. A test plan that lays out which modules you will unit test and what integration/system tests you will run. You should explain the testing approaches you will take and how you will evaluate how much testing is enough. At the very least, you should test all transitions and non-transitions of your SM, as well as have an integration test for every sequence diagram. The testing plan should describe any additional testing you will do, and how you will instrument your code in order to allow for all of the testing.

  6. An update on the final deliverable/project requirements: if the deliverable has changed/been scaled back due to challenges and/or feedback, you should describe the scope changes you’ve made. If there were comments in your proposal about how you meet the four requirements in the Project Overview section of this document, you should address these comments.

Overview slide

Provide a single slide giving a quick overview of the goals of your project! This, along with your state machine, will be shared with another group and should give someone who hasn’t heard about the project before enough information to understand what the main control module should be doing.

Hardware demo video

Record a short (2-3ish minute) video that demonstrates the progress you’ve made to get your main sensors/actuators working. You can show how your Arduino sketch is powering some motors, or a screen capture of the Serial Mointor inferfaces with the web server you’ve written, or how you calibrated your sensor. We’re not looking for a fully finished, fully integrated project at this point, but we are looking to see that you’ve made progress on some major piece of your project. The video does not need to have huge production value or even narration (some text overlays/title cards would be helpful if you choose not to narrate). You’ll post these videos to a thread on Ed, and are encouraged to ask questions about challenges you’re encountering and respond to other groups with your ideas.

Final deliverables

This section will get updated after the milestone. You’ll be working towards:

  • A report that shows evidence of your process in accordance of the V-model of software engineering
  • Evidence of individual contribution and understanding
  • Project implementation and testing code that is traceable to the report
  • A final demo that serves a celebration of all of the hard work you put into the project and shows it off to your classmates