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)|
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.
kerberos0_kerberos1_kerberos2_kerberos3.csv(where the kerberi are the appropriate student usernames) and attach it to an email sent to firstname.lastname@example.org with the title 6.08 Full Team Submission, kerberos0, kerberos1, kerberos2, kerberos3
. If you'd like help forming a team, there are a couple of options:
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 email@example.com with the title 6.08 Partial Team Submission, kerberos0, kerberos1, kerberos2
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.
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.
The proposal should be a 3-5 page PDF document that has the following sections:
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.
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).
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:
Sample milestones and demos for this system could be:
|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.
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||?|
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:
|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:
|April 21: Assemble hardware platform.||Show hardware platform to staff.|
|Put circuitry & LED panel on 3D-printed skateboard.||Show LED panel lights on skateboard responding to commands from ESP32.|
|April 21: Develop scripts to analyze sensor data.||Show script code to staff.|
|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.|
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.
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.
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.
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.
You should be attending lab times to work on your project, even when not meeting with your staff mentors.
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.
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 :
You will also need to upload your code (.ino, .py, everything)
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
Reflections on yourself
Use the box below to upload your reflections document PDF (need 1 doc from each person):
The grade for the final project will be based on:
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).
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.
\ / /\__/\ \__=( o_O )= (__________) |_ |_ |_ |_Course Site powered by CAT-SOOP 14.0.4.dev5.