Objectives

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

• Team logistcs: team name, set up google drive, team communications, etc.
• Start brainstorming, and get going on some of the subsystems
• First meeting with mentor

We have project info on the course project page, including the requirements for each project.

Logistics

Team meetings

We expect each team to meet together as a team to make progress on the project. Some of this will be sub-team meetings & work, and some will need everyone there, especially early on.

You are required to meet with your mentor each week. Every team member is required to attend. This meeting will take around an hour, depending on the week.

These check-in meetings are where we'll go over your milestones and deliverables, go over your data, talk about the project, and so on. They are graded so treat them seriously.

This week's meeting

At this week's mentor meeting, we'll spend some time going over the requirements and brainstorming about different concepts. Then we will go thru the activities for the coming week to make sure everyone is in agreement about the plan.

Team name

Your team needs a name. Spend a few minutes brainstorming on one. Then let the staff know by email or in-person.

Team bonding

We'll pay up to $100 for your team to get together for a bonding activity, as long as everyone goes and the bonding activity occurs in February. Use it or lose it!

Just keep your receipts and send a pic to Joel to process.

Successful teams will lead to successful projects. We have online resources from our colleagues in Sloan to help with working in teams.

Team documents

We'll store some documents in a Google Drive folder. 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, kailasbk@mit.edu, svenkat@mit.edu, hzyildiz@mit.edu).

Once we have your team name, we'll set up repos for you on github.mit.edu and give your team access to it.

If you want a slack workspace we can get one for you, just let the staff know.

The main activities this week

Specifications

We have set up a draft specifications document. Make a copy and place it in your team google drive. This is your central source of all information about your system.

A major task over the next two weeks is to start filling in the specifications.

Team roles & activities for the week

To make any progress you need to start to divide and conquer. We suggest that you organize your initial team roles as follows:

• Sensors
• Power management
• Firmware
• Backend/server
• Industrial design
• Concept development -- this is everyone

Later on we'll add in system integration, maybe some other areas, but for now this is a good start.

Decide who will work on each subsystem. It could be one person, two, maybe three. But for each milestone, there should be a single person in-charge.

We've created a draft milestones document. Make a copy and place it in your team google drive. This is your central source for everything you're doing over time.

Concepts

You'll want to spend time with your team talking through the requirements and making sure they make sense to you. If you have questions, check the FAQs, ask staff, and we can help you ask questions to the City of Cambridge or MITOS.

Every team member should develop an overall concept for the system -- how it might work, how it might look, any implications for the resulting system architecture. An annotated sketch is fine.

Sensors

A good activity for the sensor subsystem team is to research different sensing approaches, determine which sensing approaches to want to prototype, fill in the sensors section of the specifications sheet.

We have a variety of sensors already on-hand, so if the subsystem team determines that they want to prototype a particular sensor or two and we have it, they can get started on that this week. Otherwise, you should at least have specified which sensors (down to the part numbers) you want to order to start testing.

Power management

It's good to start to get a sense of battery capacity, lifetime, and how that stacks up in real life.

The power management team should set up two systems from lab01 and have them post their battery voltage to an endpoint every 30 sec until the system stops working. Of course, start from a fully charged battery.

Then, compare that lifetime to what we'd expect given the battery and power usage of the ESP32 when connected to WiFi and when transmitting.

So that you don't have to have your ssh tunnel active for many hours, we set up an endpoint on the class servier. You can post to the following:

http://efpi-10.mit.edu/efi_test/batt_logger?kerberos=jodalyst&bat=0.97

And then retrieve from this:

http://efpi-10.mit.edu/efi_test/batt_reporter?kerberos=jodalyst

Firmware

Fault reporting is going to be very important for debugging, especially once you are no longer connected to your computer's serial monitor. Develop and implement a scheme to communicate status information using either an external LED or the ESP32C3 on-board RGB LED.

Your system should report when everything is ok, and also report at least two faults (or their lack), such as:

• Collecting sensor data
• Connecting to WiFi
• Posting data

Basically, we want to be able to look at the indicator LED and know within 30 seconds or so that the system is working correctly, or that the system is not working correctly and which parts are not working.

Backend/frontend/server

Here we envision two tasks:

• Develop an initial wireframe model of the front end. Some people like Figma but use whatever you want. This will be your initial front-end specification
• Determine the initial specifications for your database: what data to collect and their associated datatypes

Industrial design

Determine the necessary properties for your enclosure: size, weight, ingress protection, access for maintenance, etc.

For both projects, develop initial drawings of the enclosure and how it might interact (or not) with the community.

Questions for our partners

Translating from requirements to specifications to an actual design will almost certainly need help from staff, and from our partners at MITOS and the City of Cambridge. Our partners have real jobs, with their own responsibilities. So we can't overly bug them, or expect instantaneous responses. This is the actual truth of working with customers: they aren't always available, so we need to plan to be considerate of their time.

If you have questions for MITOS or the City of Cambridge, formulate a single email and send to the 6.900-staff. Sometimes we know the answers, and if not we'll send to Jeff or Brian for their input.

Checkoff 1:
Get a checkoff from your staff mentor as evidence that you had your check-in meeting with them.

Ask for Help Ask for Checkoff Loading...