Learning Objectives

We're going to undertake several activities in today's lab. It's gonna by fun and busy!

• Intros: meet your team!
• Team names: your team needs a name
• Team google drive: you need one!
• Discuss your research: bring your research results from ex01 and discuss with the team
• Start working on your system architecture, specifications & testing plan, and milestones & deliverables

Introductions

Team assignments came out this week. Very exciting!

If you have not already met in-person as a team, now is the time to do that. If you've already met, skip to the next section.

You may not have experienced the joy of an ice-breaking activity since freshman year, so take a moment to introduce yourself to the members of your team! Spend a few minutes getting to know everyone, their reasons for taking this class, their backgrounds, and skill sets.

Team name

Your team needs a name. Spend a few minutes brainstorming on one. Once you have it, enter it here.

Enter your team name:

Ask for Help Loading...

Team documents

We'll store some documents in a Google Drive folder, which we'll create in Lab02. One team member should create a drive folder and give everyone else access. Also, give the staff access (please share with: voldman@mit.edu, jodalyst@mit.edu, raiphyj@mit.edu, zoewong@mit.edu).

Enter your team Google Drive URL:

Ask for Help Loading...

You should set up git repos for your firmware and software when the time comes on github.mit.edu. Everyone on your team, and the staff, should be given access.

System Architecture

The Sensimet project is just getting going, and now's a good time to go thru the system as you understand it with your team, and what each subsystem does. An overview of the system architecture that was used last year is here:

Research Findings

Now, onto research. Each team member researched two aspects of the system as part of EX01.

1. Upload your findings to your Team Google Drive. Put it in a suitably-named folder.
2. Go around and present your research findings to each other. Each person should spend a few minutes describing what they found, what questions they uncovered. Probably best to organize by topic rather than by person.
3. Then have a bit of discussion and Q&A from the rest of the team.
4. After all the concepts are out there, it is time for some free-form discussion. Staff will be around to answer questions and weigh in.
5. Keep notes of those discussions and an overall summary in a Google Doc.

Testing and Verification

In two weeks (!) you have your first review, and need to present a testing plan for March for the different aspects of your system.

Start working thru specifications document (see specifications problem) for more details. Now is a good time to assign specifications to team members. Key questions:

• what specs do we need?
• what should those specs be?
• how will we test to verify those specs?
• what prototypes do we need to prepare in the next two weeks in order to be ready to start testing come March 1
• what do we need to have done by Lab03 (next week) to be ready for March 1

It's alot to do! The staff is here to help, so reach out to us.

Things to Think About

Joel went over a lot of stuff in lecture yesterday. This thing needs to:

• You need to sense a few things. What are those things? What sensors do you need to do that?
• How do those sensors work? What is their power consumption? What range & accuracy do they have? What voltages do they work on? How do they communicate?
• Can you get a lot of these sensors? Are they End-of-Life or new and plentiful? How much do they cost?
• What packages do they come in? Is their packaging useful for what we need to use them for? Not all sensors are good for all use cases...some temperature sensors are really meant to sense internal enclosures only, for example.
• How are you going to control everything? We are recommending an ESP32-C3 since they are cheap and pretty easy to get. They are also Wifi/BLE enabled which brings a lot of utility. What are some useful features for this microcontroller? Do they have all the periperhals needed? Is there any reason to use something else?
• Can this thing control your sensors? Can it do so when they are all connected and present? Are there enough pins?
• What are the communications requirements of this system? Will it work in the two use cases we envision?
• How can you sense "people"? Most people last year settled on BLE and/or Wifi Sniffing...that's great...does that actually sense people? Or devices? How many devices does a person have? Is there a correlation between devices and people? Is there data out there to guide you in figuring that out? If not how can you figure that out? What experiments could you do to get a better sense of this?
• Once you have a people count, and you have sensed the required environmental parameters, what do you do with the data? Do you send it up? Miami wanted some sort of human-discomfort unit which they were kinda vague about...some sort of human-degree-pain-minute or something like that? Are there any established metrics out there for this?
• If you don't have reliable WiFi how are you going to transfer data? What are the alternatives? What are their cost? What are their problems?
• This thing needs to be battery powered...how long can a battery last? How can we keep it going? What energy sources are out there to harvest from? Can we harvest enough to run "indefinitely" or is the sensor doomed to have to get recharged somewhat periodically?
• How do the batteries work in hot/cold (though hot is more relevant for Miami and the MIT application?)
• What is the weight of the battery? size? cost? capacity? What are the pros/cons of going bigger/smaller.
• How do you charge/use a rechargeable battery?
• This thing needs to strap to a pole and survive lots of weird weather. While we're targeting Miami, we really want to target most urban centers including Boston. What do you need to be able to survive in terms of weather?
• You need to sense the environment. How do you do that while protecting those precious electronics on the inside of a box? Are there particular ways to mount sensors so they can be exposed but not too exposed?
• What materials should your enclosure be made of so that they can withstand the environment around?
• How will your system be deployed? Ideally we'll be shipping these down to Miami...how do you:
  • Box it up?
  • Install battery (or not)?
  • Guide any assembly of that might be needed...should you even have assembly?
  • How, god-forbid, can you enable someone down there to debug in some form?
  • How can you update your system remotely? (is that a possibility using the ESP32-C3?)
    • Look into OTA Updating maybe though that's not easy.
  • How do you test all of the above? Think about when you open up a fresh Apple product or an Ikea thing...they have some sweet setup instructions that engineers have thought out...you need to do that for your system.
  • Once deployed how do you know when a device is having problems (or not)? How can you tell if part or the entire system fails? If that battery fails? If someone walks off with it?
  • What overall cost (in terms of BOM for now) can you hit? 1000 is too easy. Can you do 100? $20? Less?

Milestones and Deliverables

In addition to a specifications document, you should create a milestones and deliverables document, which we'll go over each week that we don't have a review in lab.

There's more information about milestone and deliverables here.

Checkoff 1:
Before leaving, discuss your research summary, specifications, and milestones & deliverables documents to a staff member. They do not need to be completed yet, but you should have made progress.

Ask for Help Ask for Checkoff Loading...