6.S062 Final Project Proposal
Project proposals are due Wednesday, March 15, by 5 pm ET.
PROJECT LOGISTICS
We have provided a list of suggested projects at this end of this document. Please feel free to come up with your own ideas, or modify our suggestions in any way you want. Our suggestions are not complete specifications of projects.
Teams: Unless there are special circumstances approved by the course staff, you should work in teams of three. Feel free to use the class Piazza forum to find project partners.
Schedule: One- to two-page proposals (details below) are due by Wednesday, March 15, 2017. We will read the proposals carefully over the following few days and get back to you by email if we have any questions. Please don’t wait for us to get back to you; get started as soon as possible! You have about two months to carry out the project, which is ample if your proposal is focused and you start early, but not otherwise.
Proposal: A write-up in no more than two pages (11 point font or greater) that should contain the following items:
Project title (a detailed title is better than a vague one; you can always change it later if you don’t like it!) and names of the team members with email addresses.
A clear statement of the problem: a one-sentence summary followed by a one-paragraph explanation. This should identify the goal, question, or hypothesis you’re addressing.
A clear statement of your methodology. I.e., how are you going to solve the problems you’ve raised and motivated in the previous paragraph?
A statement of plan and schedule, to convince us (and yourself!) that you can complete this by the end of the term.
A list of resources you need to accomplish your work, with special emphasis on important components you don’t yet have access to. Be as clear as you can in your requirements and we will work towards getting what you need as quickly as possible. If your request can’t be accommodated for any reason, we will try to get back to you about it as soon as we find out.
Any other questions you have or clarifications you need from us.
PROJECT IDEAS
On all these topics, feel free to consult the published literature. Building on prior work is not only allowed, but it is recommended when it makes sense.
Positioning and location
Location-based messaging: build a system where users can use your app to leave messages around campus, let people discover them on their phone (possibly use anthills to determine the location), and then use their phone to retrieve messages posted at that location.
Campus tour: build a system that uses BLE-peripherals deployed around campus to provide a tour of art, hacks, or other interesting features inside of buildings at MIT. We can provide a small number of sensors (5–10) to build a prototype system in one building (e.g., the Stata center.)
Accurate BLE ranging: what is the best you can do? Conduct a rigorous set of experiments to evaluate your algorithm. How much better is it than iOS’s?
Given a set of nodes (Arduinos and/or phones), arranged in some shape or geometry, using BLE ranging (for example), develop a distributed method to have the nodes self-configure into a consistent coordinate system.
Implement the Cricket location system on laptops or smartphones using acoustic hardware available on these devices. (If it’s easier, do it on laptops.) Sound hardware on these devices seems to support the lower end of the ultrasonic frequency range. (One challenge in this project is it is not 100% clear whether it can be made to work, but if it can, it would be super-cool!)
Battery-efficient indoor-outdoor detector: On a smartphone, develop a battery-efficient way to detect if the phone is indoors or outdoors. Evaluate it systematically and fairly. (No scheme is going to be 100% perfect.) Use all tricks at your disposal, including the use of inertial sensors, screen state, history, even allowing user labeling for training if you wish. And evaluate its battery drain (to first order, how much GPS does your solution use?)
Connectivity & Networking
Build a mesh network with BLE-based radios and investigate different ways to select routes. Is the ETX metric really the best? How do different methods compare?
Build a generic protocol stack for data muling which can easily be used by smartphone applications. The stack will retrieve data from sensor nodes, store them, and deliver them. Options to provide “custody transfer” and “end-to-end ACKs” back to sensor nodes may be things your stack supports (or not – your choice).
Crowd or traffic estimation: using Wi-fi and/or BLE sniffers, could you estimate how many people walk by Stata (or other parts of campus) every day, and at different times of day? How would you measure the accuracy of your system?
Inertial sensing and its applications
Build a 2017 version of the Pothole Patrol on iOS.
Using phone sensors alone, can you detect the following actions: (a) a user holding the phone to their ear making a call, (b) a user typing on screen. No spying on apps. It’s OK to check screen state, but primarily you should use the phone sensors. In addition to developing the method, focus on evaluating it systematically and fairly. (No scheme is going to be 100% perfect.)
Conduct a careful empirical evaluation of iOS’s M7 activity monitor. Define performance metrics, justify them, and measure how well M7 does.
Data cleaning and data quality
Automatic map production: using smartphone position and/or inertial sensors, develop a system and app to create or augment maps. You can apply this to walking trails, for example, or to roads, or to add information such as the location of signs or one way roads to existing maps. You can decide the domain. As a bonus, publish your contributed tracks or trails to OpenStreetMap (Open Street Maps). We can provide a large number of traces of historical taxi data in Boston, and similar data can be found online (we will use some of this data in Lab 4).
Build a system that keeps track of common sequences of locations a user travels on a weekly basis, using iOS significant change, region monitoring APIs, and geo-coding APIs. The challenge here is filtering out locations that are infrequent from frequent origin/destinations, and determining when several nearby addresses are actually the same.
“Air gestures”: build a system that uses the gyroscope and accelerometer to perform a range of “air gestures” e.g., to control lights in a building or send messages to friends. The challenge here is identifying which of several gestures a user performed.
Build a TinyDB clone that runs on ad-hoc networks of phones or other devices? Which of the optimizations in the paper are still relevant today? Can you think of new optimizations
Personal health and wellness
Existing smartphone apps are good at tracking some fitness activities like running and cycling, but don’t do a good job with many other sports. Build an exercise tracking app for a fitness activity of your choice. For example, can you use an iPhone or BLE device strapped to your arm to measure different types of weightlifting activities, or their intensity (by looking at acceleration and gyroscope signals)? Or can a similar configuration be used to reconstruct the sequence of plays in an outdoor game like basketball or soccer? Rowing? Skiing? Tennis?
Fall detection: Detecting people falling is a classic problem that people have worked on (and continue to work on). Develop fall detection software with either: (1) wearable sensors (accel, gyro) prototyped on iOS or Arduino, or (2) cameras. (There are two distinct projects here.)