Final Project Logistics

The questions below are due on Wednesday March 15, 2017; 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 (https://oidc.mit.edu) to authenticate, and then you will be redirected back to this page.

1) Timeline and due dates

All due times are 11:59 PM unless otherwise specified.

Saturday April 7 Teams due
Sunday/Monday April 8/9 Teams Assigned
Friday April 13 Project proposal due
Monday/Tues April 16/17 Mentors assigned, project feedback provided, mentor meeting times assigned
Thursday April 19 Deliverables 0: All teams Meet with staff mentors during lab time in abbreviated meetings!
Tuesday April 24 or Thursday April 26 Deliverables 1: with staff mentors
Tuesday May 1 or Thursday May 3 Deliverables 2: with staff mentors
Tuesday May 8 or Thursday May 10 Deliverables 3: with staff mentors
Tuesday May 15 and
Thursday May 17
Deliverables 4: with staff mentors
Thursday May 17 Project reports due @11:59pm
Friday May 18 Optional Demo Day (TBD)

2) Forming teams

Start forming teams now! You must work in teams of 4.

2.1) Full Team Known

If you know who you want to work with (and have four team members), email jodalyst@mit.edu the following email format:


Title: 6.08 Full Team Submission
Body:
kerberos1, kerberos2, kerberos3, kerberos4
A list of section times when all four members can meet (be as flexible as possible with this to ensure teaming. List hour-ranges in any Section window. For example, if your whole team can meet from 9:30-10:30 am on Tuesdays and Thursday's even if you are section 3, consider putting this down). Getting your meetings

Because of the large enrollment in section 3, we cannot 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 section 3 for meeting time. Consider offering Section 1 or Section 2

2.2) Be Assigned a 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 submssion up above.
  • Email the staff to be placed into a team. If you do that, send an email to jodalyst@mit.edu with the following email format:


Title: 6.08 Team Placement Request
Body:
kerberos
A list of section times (time windows) when you can meet.

2.3) Partial Team

If you have a partial team, it will probably be better to first pitch the project on piazza to attract like-minded individuals. If that doesn't work, email jodalyst@mit.edu the following. Note, doing this may result in your team of two being combined with another team of two for example, in which case projects might need to be adjusted, depending on situation.


Title: 6.08 Partial Team Submission
Body:
kerberos1, kerberos2, kerberosn (where n<4 and n>=2. if n==4: full team email)
A list of section times when you can meet.

If you want help teaming, please email us 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 section time (no exceptions. All team members are expected at check-in meetings. If this does not happen significant point penalties will be applied). We will then pick the section and day (either Tuesday or Thursday) at which you'll have your weekly mentoring meeting.

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 or a 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 19th 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

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.

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 presentations

On Tue and Thu May 15-18, each team will give a 12-20 min demo of their system for the staff. The actual duration of the demos will be decided early in May.

We will assign demo times based on preference and availability. We'll collect preferences sometime near the end of April.

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 demoed 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 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, etc.).

Please place your report PDF 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
  • 10% Meeting teaming and proposal deadlines (did you team turn in its proposal on time?)
  • 20% on the final presentation/demo.
  • 20% on the quality and content of the documentation.

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.


 
Footnotes

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