Final Project Logistics

Back to Final Project Overview

---

1) Timeline and Due Dates

See notes below table for various action items on each task.

Friday April 3	Teams due
Friday-to-Monday April 3-6	Teams Assigned
Thursday April 9 or Tuesday April 14	Meeting 0: with staff mentors
Thursday April 16 or Tuesday April 21	Meeting 1: with staff mentors
Thursday April 23 or Tuesday April 28	Meeting 2: with staff mentors
Thursday April 30 or Tuesday May 5	Meeting 3: with staff mentors
Thursday May 7 or Tuesday May 12	Meeting 4: with staff mentors
Tuesday May 12	Project reports and reflection documents due @11:59pm

2) Project Proposal

Your project should meet the project guidelines listed [here](COURSE/final_project) and [here](COURSE/final_project/overview). If you have questions about whether a project idea fits into the guidelines, please post on Piazza so we can answer for everyone to see.

The proposal should be an html document (approximately the length of five regular pages) that has the following sections:

• One-paragraph overview of the entire project
• More detailed description of the intended functionality, including a system block diagram and tentative state machine diagrams (high level stuff)
• Technical challenges that you foresee
• Parts list, if applicable. The parts list should have description, item number, vendor, and price.
• A preliminary milestone and demo table, as described in the next section. This does not mean you will must stick to this timeline for the whole time, and in fact, we expect many teams will have to adjust as they move through the final project phase.

One student in the team should upload your final project proposal to the course website (location of upload spot TBD).

Make sure your proposal meets all the guidelines posted above. If we need to iterate with your team on your proposal because of missing content from above, it will cost you in time and grade.

3) Milestones and Meetings

Each week (on either a Tuesday, or Thursday depending on what day you get assigned), your full team is to meet with your staff. The 0th week will be focused on discussing your proposal, but in rest of the weeks, you'll be demonstrating milestones that you set out in the previous week as well as discussing next steps (did you achieve everything you needed to for the week? Then keep going? If not, maybe pivot/adjust some goals. Or maybe a missed goal from this past week becomes a goal again for the next week).

An important part of managing a long-term team project is effective time management. The purpose of the milestones and demos are to keep you on track to avoid a heroic effort right at the end. This is for your benefit!! Your grade will be based significantly on these. There will be five milestone meetings (0 through 4, with 0 being on April 9th and 14th and the 4th being your last meeting coinciding with the final demo).

3.1) What's a Milestone? What's a Demo?

A milestone is accomplishing a particular task in the evolution of the project. A demo is how you demonstrate that you have accomplished that task. Think about breaking down your project into subsystems and tasks performed by those subsystems. Then think about what tasks you need to accomplish as you put those subsystems together to create the complete system.

For example, in 2016's refrigerator monitoring project, the team wanted to create a system to monitor the temperature and door-opening status of their dorm fridge. That project has a number of parts:

1. choosing what to sense and how to sense it
2. creating the hardware platform that will live in the fridge
3. writing the code to sense the temperature
4. writing the code to sense the door opening
5. testing the embedded system to make sure it accurately measures temperature and door opening
6. writing the server-side code to receive the data from the fridge and send it to a database table
7. writing server-side code to visualize the data
8. testing the server-side code with synthesized data
9. testing the system end-to-end

Sample milestones and demos for this system could be:

Milestone	Demo
Choose temperature sensor and two potential door monitoring sensors	Show that parts have been ordered
Write server-side code to visualize the data	Show real-time rendering of plots of temperature vs. time and door-opening vs. time based on synthesized data.

You can see that some tasks depend on prior tasks. For example, you can't write the code to sense the temperature until you've obtained the temperature sensor. Think about staging milestones and demos based on dependencies.

Think also about what each team member will do each week. What prior tasks does that person depend on? Make sure that everyone has something to do. In fact, each milestone and demo should list who's responsible for the milestone and demo.

3.2) Creating Milestones and Demos

As part of your proposal, you will create a Milestones table. Well-written milestones and demos are easy to interpret. For example, here is a poorly written milestone and demo:

• April 21: Work on code to read sensor input

**BAD**

Milestone	Demo
April 21: Work on code to read sensor input	?

This is not a useful milestone because it is really a task (what you'll be doing) rather than a milestone (what you'll accomplish). One could "work" on code for various amounts of time and make various amounts of progress. In addition, no demo is proposed. Looking at your code with the staff by itself is not a good demo! Here is a better-written milestone and demo:

**GOOD**

Milestone	Demo
April 21: Finish ESP32-side code for reading values from humidity sensor and sending to Seral port.	Show streaming sensor values on Serial monitor as humidity is changed by breathing on sensor.

Your project should have more then one milestone and demo each week. This is because you'll want to break down your system development into parts that each teammate can work on, and you want each teammate to have responsibilities each week.

Here are some more examples:

**BAD**

Milestone	Demo
April 21: Assemble hardware platform.	Show hardware platform to staff.

**GOOD**

Milestone	Demo
Put circuitry & LED panel on 3D-printed skateboard.	Show LED panel lights on skateboard responding to commands from ESP32.

**BAD**

Milestone	Demo
April 21: Develop scripts to analyze sensor data.	Show script code to staff.

**GOOD**

Milestone	Demo
April 21: Develop script to analyze sensor data and plot temperature versus time with 1-min resolution	Show plot of temperature versus time in response to door opening and closing.

3.3) Minimum Viable Product

In developing your proposal and milestome/demo schedule, think about what is the minimum viable product, or in other words, what is the minimum system that gets at the essentials of what you want to do. Sure, your final system will have some bells and whistles, and you want to reach to do something hard, but make sure you have something working early in the process. In the example of the refrigerator monitor, maybe a minimum viable product shows the current temperature and door status on a web page, with a listing of the last 10 uploaded data points. Once you have that working, you can move on to the fancy graphics, or add in a third humidity sensor, etc.

What you don't want to do is to set up your schedule so the first end-to-end test of the system is the weekend before the project report deadline. Because your first end-to-end test won't work. So you want to iron out those issues early, create an alpha version or beta version, and then have time to improve it.

3.4) Mentor meetings

Each team will be assigned staff mentors. Their role is to help you realize your project and to assess your progress. Each team will meet with their staff mentors for 30 min at a pre-assigned time during the Tuesday and Thursday lab sections. We will send out the schedule prior to April 7.

Each week's milestone and demo will be graded by your mentors.

3.5) Revising milestones and demos

Your initial set of milestones will be a best guess as to how the project will proceed. You'll find that your best guess is not very good. Some things will be easier than anticipated. Some will be harder, and will either take longer than anticipated or will need to be re-evaluated (for example, midway through your project you may devcide that using a joystick is not the best approach and you'd rather use buttons).

We want to allow you to revise milestones and demos. After each Tuesday or Thursday meeting, you will have until the following evening, to submit a new set of milestones/deliverables. Alert your mentors as to any proposed changes via email. There will be a submission page for each team on the site. They will approve or disapprove. Then the milestones stay fixed until the next Tue/Thu mentor meeting. Editing milestones after Friday (for Thursday groups) or Wednesday (for Tuesday groups) will result in a zero for that week's milestone/demo grade.

4) Lab hours

During the project period (April 9 to May 14), we will not have new labs. Instead, all staff will be present during lab hours to discuss your project and to help debug.

You should be attending lab times to work on your project, even when not meeting with your staff mentors.

5) Final Report

we thought it would be better to have teams create simple websites to demonstrate functionality. In this way you can utilize more varied multi-media We'll provide some templates for this as needed.

We'll provide more details of your final project page as we get closer, but :

• Documentation of your system. Think about it as the how-to instructions similar to the lab handouts. What does someone else need to know in order to replicate your system?
• Functional block diagram(s) of the system.
• State machine block diagram.
• Discussion of the design challenges and rationale for decisions made.
• Parts list for any parts not in our base system.
• Detailed description of your code (what does each function or class do, what is the high-level role of each piece of the code?)
• Discussion of your approach to energy management

You will also need to upload your code (.ino, .py, everything)

Finally, each person will create a ~1-pg "reflections" document, which should explicitly touch upon the following two sets of questions¹ (Note this document does not and shuld not need to be shared with your partner):

Reflections on your team

• How do you feel the team did?
• How well did your team work together?
• How was the coding?
• How did you split up the work

Reflections on yourself

• How do you think you did?
• What specific contributions did you make?
• How do you feel about those contributions?
• What behaviors (things you do, rather than things you feel, or goals you have) do you want to keep, start, or stop doing in future projects?

6) Public Sharing

People often want to share their code publicly, e.g., on Github, in order to show off a portfolio of code they’ve written to potential employers. Building a portfolio is a great idea, but the 6.08 class project (and design exercises, labs, and exercises) is not a good class to use for it, because the problem sets and design exercises are fixed by the course staff, not chosen by you. In addition, the design projects are highly likely to use code developed through the regular homeworks (like the Button class, or the Ball class, etc.). We do not want these blocks of code to be publicly available, and so do not want the project code to be public.

Feel free to share videos of your work. You can send code to an employer privately. If you really really want to share code publicly, you can ask for permission from us and we'll review on a case-by-case basis. But you need to ask before sharing.

This policy is adapted from 6.031's public sharing policy.

Back to Final Project Overview
 

---

Footnotes

¹These are based on questions used in 6.005 (click to return to text)

\            
/    /\__/\  
\__=(  o_O )=
(__________) 
 |_ |_ |_ |_