Final Project Logistics

Spring 2019

The questions below are due on Wednesday May 15, 2019; 05:00:00 PM.
You are not logged in.

If you are a current student, please Log In for full access to the web site.
Note that this link will take you to an external site ( to authenticate, and then you will be redirected back to this page.

Back to Final Project Overview

1) Timeline and due dates

All due times are 11:59 PM unless otherwise specified and exist in the Calendar Year 2019

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

Sunday April 7 Teams due
Monday/Tuesday April 8/9 Teams Assigned
Sunday April 14 (@12pm NOON) Project proposal due. Please, for the sake of all that is holy, recognize that this is CPW so get this done before it starts if you're doing a bunch of stuff for it. Please. Please. We can't do extensions on this since we need this information for the staff to review.
Tues/Wed April 16/17 Mentors assigned, project feedback provided, mentor meeting times assigned
Thursday April 18 Deliverables 0: All teams Meet with staff mentors during lab time in abbreviated meetings!
Tuesday April 23 or Thursday April 25 Deliverables 1: with staff mentors
Tuesday April 30 or Thursday May 2 Deliverables 2: with staff mentors
Tuesday May 7 or Thursday May 9 Deliverables 3: with staff mentors
Tuesday May 14 or Thursday May 16 Deliverables 4: with staff mentors
Thursday May 16 Project reports due @11:59pm
Friday May 17 Optional Demo Day (TBD)

2) Forming teams

Start forming teams now! You must work in teams of 4. If you are further along in your Course 6 studies, such as a Junior or Senior, we would like to see you work with other Juniors and Seniors so that your team is internally at a similar level.

Follow the instructions below carefully. You may not get teamed up as you want and/or can lose points if you do not follow the directions.

Use the teaming preferences CSV file here.

2.1) Full Team Known

If you know who you want to work with (and have four team members), follow the instructions in the CSV file completely, filling out the entire form. Rename the file kerberos0_kerberos1_kerberos2_kerberos3.csv (where the kerberi are the appropriate student usernames) and attach it to an email sent to with the title 6.08 Full Team Submission, kerberos0, kerberos1, kerberos2, kerberos3

Because of the large enrollment in section 2 and possibly 3, we cannot necessarily accept more students into that section. There is no guarantee that your team will be kept together if you are bringing students from outside sections into sections 2 or 3 for meeting time. Consider offering Section 1 or Section 4

2.2) Be Assigned a Team or Submit a Partial Team

. If you'd like help forming a team, there are a couple of options:

  • Post project ideas on Piazza and see who is interested in joining you....when a team is assembled follow the full team submission instructions up above.
  • Submit a partial team (including Team of 1). To do that follow the instructions in the CSV file above completely, filling out the entire form, leaving unknown students blank. Rename the file in the style kerberos0_kerberos1_kerberosn.csv (where the kerberi are the appropriate student usernames and the number of kerberis listed matches the number of students in the partial team) and attach it to an email sent to with the title 6.08 Partial Team Submission, kerberos0, kerberos1, kerberos2

If there is another teaming concern, please email by Friday of the week that teams are due so we have time to help!

It is easiest to form teams within your section. If you want to form a team with people in other sections, you can do so, but all members must be free to meet in a single block time (NO EXCEPTIONS. All team members are expected at check-in meetings. If this does not happen significant point penalties will be applied). We also cannot guarantee all a given section will be availble if people are coming from outside sections, so be flexible in your scheduling. We will then pick the meeting time slot and day (either Tuesday or Thursday) at which you'll have your weekly mentoring meeting. Please do not try to be a picky team in this process. If you provide only one meeting time slot, and think that will force us to put you there, that may backfire and your group will need to be split up.

This is important: If you team is missing members at meetings, you will lose points.

3) Project proposal

Your project should meet the project guidelines listed here. 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.

We are happy to provide initial feedback on proposal ideas via Piazza, in office hours, or during lab time.

The proposal should be a 3-5 page PDF document 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.
  • You will also make a milestone and demo table, as described in the next section.

One student in the team should upload your final project proposal to the google drive.

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.

Note that late penalties of 5%/hr will apply for this deliverable. Any late penalties are based on the timestamp for the last uploaded or edited document. This deliverable is not eligible for automatic one-week extensions.

4) Milestones and Meetings

Each week (on either a Tuesday, Wednesday, or Thursday depending on what day you get assigned), your full team is to meet with your staff. The only exception to this is on April 17th and 18th when all teams will meet with their staff advisors/mentors in abbreviated deliverable 0 meetings (where you should shoot to have one or two initial deliverables in place).

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 19th and 4 coinciding with the final demo).

4.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.

4.2) Creating milestones and demos

As part of your proposal, you will create a Milestones spreadsheet. We've provided a template in the Google class-wide folder. Copy that template into your team folder and then fill it out. You sheet will include a list of milestones and associated demos to hit for each Meeting Day meeting, so milestones for April 20, 27, etc. 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

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:

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:

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

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

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

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.

4.3) Minimum Viable Product

In developing your proposal and milestome/demo schedule, think about what is the minimum viable product, aka 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.

A good project schedule will get to a minimum viable product by May 4.

4.4) Mentor meetings

Each team will be assigned two 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 Thu lab sections. We will send out the schedule prior to April 14.

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

4.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 Wednesday or Friday evening (one day), respectively to propose any revisions to your milestone and demo table. Alert your mentors as to any proposed changes via email. They will approve, disapprove, or revise by end of Friday if you are a Tuesday demo-day-group or Sunday if you are a Thursday demo-day-group. Then the milestones stay fixed until the next Tue/Thu mentor meeting. Editing milestones after Friday (for Tuesday groups) or Sunday (for Thursday groups) will result in a zero for that week's milestone/demo grade.

5) Lab hours

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

Although you are assigned a set of staff mentors, you can contact anyone on staff for help.

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

6) Final Demo/Presentation

On Tue and Thu May 14-16, each team will give a 30 min final demo of their system for the staff. In some sense this is just like a more intense overall deliverable meeting, but it should be as demonstration-based as possible. Do not expect staff to be helping you debug your stuff in the thing.

During each demo, teams will demonstrate their system and answer questions from the staff. You should be prepared to discuss your system block diagram and state machine diagram, and lots of other features.

If your system is not able to be fully demonstrated indoors, you should upload and play a video of it working, though we'll also want to see at least some aspect working during the presentation.

7) Final Report

In previous year's we've had students write a report, but this year, 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)

Please place your report resources and code files in your Google drive team folder prior to the deadline.

Finally, each person will create a ~1-pg "reflections" document (in PDF), which should explicitly touch upon the following two sets of questions1 (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?

Note that late penalties of 5%/hr will apply for the final report, code, and reflections documents. Any late penalties are based on the timestamp for the last uploaded or edited document. These deliverables are not eligible for automatic one-week extensions.

Use the box below to upload your reflections document PDF (need 1 doc from each person):

 No file selected

8) Grading

The grade for the final project will be based on:

  • 20% on creativity and reach, i.e., choosing an interesting, challenging project and keeping the project interesting and challenging throughout the course of the final project
  • 30% on meeting your weekly milestones and demos and submitting a clear proposal (excluding final deliverables)
  • 10% Meeting teaming and proposal deadlines (did your team turn in its proposal and all deliverables on time?)
  • 20% on the final presentation/demo (basically evaluation of your final deliverables)
  • 20% on the quality and content of the documentation (final report)

In addition you will provide a detailed assessment of the teamwork of your group and this will be used in part in determining an individual grade as well (to assess how well you worked within the confines of your team).

9) 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


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

This page was last updated on Monday May 06, 2019 at 09:34:22 AM (revision eed47b9).
Course Site powered by CAT-SOOP 14.0.4.dev5.
CAT-SOOP is free/libre software, available under the terms
of the GNU Affero General Public License, version 3.
(Download Source Code)
CSS/stryling from the Outboxcraft library Beauter, licensed under MIT
Copyright 2017