Link Search Menu Expand Document
CSCI 1600, Fall 2025

Project

Table of contents

  1. Project overview
  2. Timeline
  3. Proposal (Due Friday, Oct 10 at 11pm)
  4. Progress milestone (week of Nov 10)
    1. Milestone report (due Tuesday, Nov 11 at 11pm)
    2. Presentation (Monday and Tuesday, Nov 11 and 12, during lab time.)
    3. Final demo (reading period)

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
  • Timer/Counter

The idea and execution must demonstrate design skills and creativity, culiminating 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

  • Friday, Oct 3: Project groups assigned

  • Friday, Oct 10: Proposal due

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

  • Nov 11 and 12 (during lab time): Milestone presentations

  • Reading period (date TBD): Final demo

Proposal (Due Friday, Oct 10 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. Keep in mind that the course is providing each group has a budget of about $10-$15 (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 20. Factor in about a week of processing and shipping time to receive the hardware.

Progress milestone (week of Nov 10)

The progress milestone consists of a report (composed of artifacts from the left/design side of the software engineering V-model), a short presentation/demo, and peer reviews.

Hand in your report to Gradescope. On the week of the milestone presentation, we will also have a Google form where you will have to turn in your FSM and presentation slide for peer review.

Milestone report (due Tuesday, Nov 11 at 11pm)

Your report should have the following sections:

  1. Clear, concise, complete, and confirmable 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 finite state machine that describes the detailed design of the main module of your system, as described in class. You should clearly define the inputs, outputs, and FSM 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 FSM, 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. Note that you should have your FSM ready in time for the demo (Nov 10 or 11, see below).

  5. A test plan that lays out which modules you will unit test and what integration and system (software and user-facing/acceptance) 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 FSM, 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.

Presentation (Monday and Tuesday, Nov 11 and 12, during lab time.)

We’ll send out a scheduling form to assign groups to the different labs so that as many people in your group are present as possible.

You should prepare a single slide with a quick summary of the project goals, progress, and challenges. Don’t present your report here – we just want a quick (1 minute or so), high-level introduction to give people context of what your project so that they can understand your demo and reason about your FSM. The majority of the presentation should be a live demo (not recommended unless you’ve practiced thoroughly) or video (recommended) of any hardware or software libraries you have working. This can just be a video showing that you powered a motor, or a screen capture of the serial monitor interfacing with a web server you’ve written, or something similar. Even if you don’t get your hardware/libraries working successfully in time for the presentation, you can show what you’ve tried and then use the rest of the presentation time to talk about challenges/future strategies.

Because we have 16 groups (8 per day), practice ahead of time to make sure your presentation fits within the 5 minutes so that your classmates also get a chance to present. This time goes quickly, so we’re not looking for a big presentation!

Your FSMs will be peer-reviewed by other groups in the second part of lab time and again as a homework assignment.

Final demo (reading period)

This demo is meant to be a celebration of all the hard work you put into making your project! You will get to show your classmates what you’ve accomplished and get to see what they accomplished. Have fun with it.