Project
Table of contents
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
Thursday, Oct 3: Project groups assigned
Friday, Oct 11: Proposal due
Week of Oct 14: Proposal feedback received, parts ordering begins
Nov 6 and 8: Milestone presentations
Proposal (Due Friday, Oct 11 at 11pm)
Write a project proposal (about 1 page) that has the following sections:
High-level overview of what the project will be.
Explanation of how the project will fulfill the requirements above.
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?
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.
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.
Preliminary list of parts to be ordered, with links. We will give initial feedback for this before ordering parts. Keep in mind that each group has a budget of $40.
Any resources (datasheets, libraries, videos) you’ve consulted in writing this report.
We’re aiming for parts orders to be placed by October 21. Factor in about a week of processing and shipping time to receive the hardware.
Progress milestone
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 5 at 11pm)
Your report should have the following sections:
Clear, concise, complete, and confirmable requirements for your project, written with “shall/should” language as defined in class.
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.
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.
One finite state machine that describes the detailed design of the main module of your system, as [escribed in class. You should clearly define the inputs, outputs, and 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 6 or 8, see below).
A traceability matrix of how the transitions and states of the FSM in step 4 trace to the requirements in step 1. If your system is made up of multiple modules, you will not have full traceability from just one FSM, so you are not required to have a check in every column (requirement) of the matrix. Traceability matrices were covered in the FSM lectures.
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, as described in class You should explain the testing approaches you will take and how you will evaluate how much testing is enough
An update on the final deliverable/project requirements: if the deliverable has changed/been scaled back due to challenges and/or feedback, you should include updated versions of parts 1 and 2 of the proposal. 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 (Wednesday, Nov 6 and Friday, Nov 8 during lecture)
You should prepare a single slide with a quick summary of the project goals, progress, and challenges. In class, you will do do a brief (5 min) presentation, which can include a demo of any hardware you have working, or just a discussion of what you’ve tried so far. Because we have 14 groups (7 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 as a homework assignment.
Final deliverables
Report (Initial due date: Dec 12 @ 11pm, Receive feedback by EOD Dec 15, Revisions due Dec 17 @ 11pm)
Write a report that has the following sections:
A short introduction giving an overview of your project and what assumptions you are making about the user.
*Revised and fleshed out requirements from part 1 of the progress milestone report.
*Revised architecture diagram from part 2 of the milestone report.
Three sequence diagrams for reasonable use case scenarios of your system (if there are more than 3, you should pick the 3 most likely use case scenarios to diagram, and include a note as to what scenarios you left out). Before *each diagram, you should write a short (1-2 sentence) description of what the use case scenario is.
*Revised finite and/or extended state machine from part 4 of the milestone report. See part 13 below for directions on including your peer review feedback as an appendix.
*Revised traceability matrix from part 5 of the milestone report.
*An overview of your testing approach, including which modules you unit tested and which integration and system (software and user-facing/acceptance) tests you ran. You should explain how you determined how much testing was enough (i.e. what coverage or other criteria you used, how you measured that you achieved that criteria, and why you think it is sufficient for you to have met that criteria).
At least 2 safety and 3 liveness requirements, written in propositional or linear temporal logic, for your FSM. Include a description in prose of what the requirement represents. Each requirement should be a single logic statement, made up of propositional and/or linear temporal logic operators, that references only the inputs, outputs, variables, and states defined in part 5 of this report. We will discuss safety and liveness requirements on the week of November 27th. You can also refer to chapter 13 of Lee/Seshia or chapters 3 and 9 of Alur’s textbook (Brown login required).
A discussion of what environment process(es) you would have to model so that you could compose your FSM with the models of the environment to create a closed system for analysis. Composing state machines was covered during the modeling lectures. For each environmental process, you should explain and justify whether it makes sense to model it as either a discrete or hybrid system and either a deterministic or non-deterministic system (for example, a button push could be modeled as a discrete, non-deterministic signal because it is an event that could happen at an arbitrary time, but a component’s position could be modeled as a hybrid, deterministic signal based on some acceleration command). You are not being asked to actually do this modeling or any sort of reachability analysis, just to reason about this sort of modeling at a high level.
A description of the files you turned in for the code deliverable. Each file should have a high-level (1-3 sentence summary) description. For each of the assignment requirements (PWM, interrupts, serial, etc), you should indicate which file(s) and line(s) of code fulfill that requirement.
A procedure on how to run your unit tests (for example, if you have mock functions that are used by setting a macro, similar to lab 6, make sure to note that).
A reflection on whether your goals were met and what challenges you encountered to meet these goals. You should only include challenges met or newly addressed since the milestone.
As an appendix, include the review spreadsheets you received after the milestone demo. Each defect should be marked as “fixed” or “will not fix” with a justification.
Any sections marked by an asterisk (*) should incorporate feedback from the progress milestone report.
Individual report (Dec 17 @ 11pm)
Each team member should also produce an independent report that has the following sections:
An overview of your personal contributions to the project (which part(s) of the code, final deliverable, report you did or helped with).
For each of the assignment requirements (PWM/ADC/DAC, watchdog, ISR, WiFi/Serial/timer), in your own words, explain how the requirement is being met. For PWM/ADC/DAC, watchdog, and ISR, we are looking for you to demonstrate understanding of the purpose and nuances of these peripherals as discussed in class and how they apply to your project. Thoroughly explain how the hardware and software design and behavior of your specific project makes use of these peripherals and why your team chose to incorporate them where you did in the project.
Any extenuating factors or important information about your team dynamics that you would like to share (this will be kept confidential).
Code (Dec 17 @ 11pm)
Include all of your project code in a zipped file. Any code included here should have a summary in Part 10 of the project report. We should be able to run your unit tests according to Part 11 of the project report, and all tests should pass. The FSM implementation of your code should follow the conventions learned in class and should have annotations for each transition. All functions in the code should be commented with descriptions of the high-level behavior, inputs, outputs, and side effects.
Form for website (Dec 17 @ 11pm)
To receive a grade for the final project, your group must fill out a form (linked in December) that asks you to upload/include links to a photo/optional video of your project, your flier or slide (see below), and an optional github link. We’ll ask your permission to display these on the course website as a celebration of your work.
Demo (Dec 10)
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.
In lieu of a presentation, prepare a flier (half page-page) or slide to display on a laptop that you bring to the demo. If you want us to print the flier, you should e-mail it to the course staff [deadline TBD]. The flier or slide should contextualize your project by giving user-facing product requirements and should explain any assumptions you are making about the users of your project. Remember that user-facing product requirements can simply be the features of your project, described from a marketing perspective.
During the demo time, you will have a designated spot in the classroom to show off your project. You should have all of your hardware and any equipment necessary to demonstrate your project. If you need any special accommodations (multiple outlets, table size requirements, etc) for your demo, contact the course staff. During the demo, at least one person should be at your station at any given time to answer questions and do a demonstration, but otherwise you will be free to walk around and admire your classmates’ projects. The entire team will be expected to be available to answer questions that course staff will have.