Sentimet Project

You are not logged in.
Please Log In for full access to the web site.
Note that this link will take you to an external site (https://shimmer.mit.edu) to authenticate, and then you will be redirected back to this page.

What's on this page

This is your landing page for information related to the semester project with Miami-Dade County and the MIT Office of Sustainability, which we're calling Sentimet.

Here we have schedule, information on working as a team, requirements & specifications, notes on various aspects of the design, and so on.

Reviews

Schedule

To help keep everything straight, here is the current schedule for the Sentimet project.

You can think of the project as broken into roughly 3 phases:

Now until February 28

In the first few weeks you are preparing for the March testing, where the goal is to test subsystems and approaches to get to a system that meets specs by March 20. That means that in February you need to develop specs, a testing plan, and develop the prototypes you'll need to enact that testing plan.

March until March 20

First round of testing, along with revision of the design based on those results. The goal is to get to an alpha prototype by March 20, which basically means a system that meets specs, but doesn't necessarily look good.

March 20 to April 29

In this round, you revise the system and integrate all the parts together, culminating in creation 10 systems that we can ship to partners on April 29. These should meet spec and work!

April 29 to May 13

Field testing, both remotely and at MIT. You'll have limited ability to revise the HW at this stage, though FW/SW changes may be possible depending on your design. Of course, it will be easier to adjust things for the MITOS system than for the Miami-Dade one!

May 13 are the final presentations!

Some team logistics

Succesful teams will lead to succesful projects. We have online resources and are planning to have a colleague in Sloan to give a lecture helping with working in teams.

Here are some important notes:

Team name

You need a team name. Come up with one in early on, in Lab02.

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.

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.

Team coordination

Starting in Lab02, there will be a weekly meeting with the team and at least one staff member to check in, and go over milestones and deliverables. You can also use some Lab time for team work (some labs will be entirely dedicated to team work).

But this won't be enough time. You'll need to schedule other times to meet, and can set up other avenues to collaborate. You can have a team Slack channel, and however else you wish to communicate.

Team roles

Prior to the first set of presentations on February 28 you'll decide on the technical roles of each team member. We'd like the team members to each have defined technical roles. That doesn't necessarily mean that if Jane is the firmware lead, that only Jane does firmware, but it does mean that it's ultimately Jane's responsibility.

There are other, non-technical, roles that are important, and that should be assigned by the team:

Ordering. One person should be the conduit to handle ordering of parts.
Note-taker. One person should make sure to take notes from team meetings and place that in your Google Drive subfolder. This person should also take pictures each week of what is being worked on, including the students, and deposit that information in a different Google Drive subfolder.

It's fine (even preferable) to rotate the non-technical roles over the course of the semester.

Mentor Questions

Translating from requirements to specifications will almost certainly need help from staff, and from our partners in Miami-Dade and MIT Office of Sustainability. 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.

The mentor liaison is the main point of contact to ask questions of the mentors.

Please craft only send one email to your mentors each week.

Send that email to the staff and we'll forward it along to the right set of people for response.

We have a running FAQ with questions & answers that may be useful. We'll add to this FAQ over the semester as questions/answers come in.

Note-taker

The note-taker has two jobs: take notes, take pictures. Notes are important so the team has a shared understanding of what goes on in each meeting, who is going to do what in the upcoming week, and so on.

The other job is to take pictures: we think this project is cool, and we want the world to know about it. So we will distribute updates during the semester via various social media channels.

The note-taker should be taking pictures during team meetings, team work, lab sessions, and so on. Find a few each week (5? 10?, sounds about right) and place those in your google drive folder (jpg, png, any typical format), along with a tag of 1) who's in the picture, 2) who took the picture, and 3) what they're doing.

Requirements

The purpose of this system is to improve the bus transit system in Miami-Dade County by providing information to the County to help them understand where to prioritize deployment of resources to improve the comfort of bus stops. The way to do that is to obtain local measurements of the "heat experience" at particular bus stops, along with a sense of how many people are waiting, and for how long. This information can be combined with static and dynamic real-time information already obtained by the transit system. Carlos' presentation from Lecture 2 is available to review.

Based on this, a starting set of requirements for the system are:

It should measure the "heat experience" at each bus stop, at least temperature and humidity, but also could include air quality, all with dynamics appropriate for the use case.***
It should be able to measure how many people are waiting, and for how long.***
It should operate without being connected to line voltage. ***
It should be installable by a technician, and should be easy to set up.***
It should report faults, such as battery failure, falling, vandalism, etc.**
It should be as inexpensive as possible. *
Data from a sensor node should be able to be tied to a location.***
It should maintain privacy. ***
It should operate independently without user intervention for at least a month. ***
It should be rugged and able to withstand shipping, setup, and operation in the Miami-Dade environment. ***
Multiple systems should be able to be used simultaneously. ***
The system should incorporate data from Swift.ly and present that information to the operator in a useful way. **

where the number of ' * 's denotes the importance of that requirement.

For the MIT Office of Sustainability, the requirements are very similar:

It should measure the local weather, at least temperature and humidity and ideally also sun exposure and ground surface temperature and air temperature, all with dynamics appropriate for the use case.***
It should be able to measure how many people are in the area passing through (e.g., foot traffic) and lingering.***
It should operate without being connected to line voltage.***
It should be portable and able to be set up by an average person in a variety of outdoor environments on the MIT campus, including on a tripod or attached to poles of various dimensions.***
It should be able to be physically attached to a HOBO MX2302A data logger.*
It should report faults, such as battery failure, falling, vandalism, etc.**
It should be as inexpensive as possible.*
Data from a sensor node should be able to be tied to a location.***
It should maintain privacy. ***
It should operate independently without user intervention for 2+ weeks. ***
It should be rugged and able to withstand a summertime Boston-area environment (heat, rain, wind and curious people). ***
Multiple systems should be able to be used simultaneously. ***
The system should present the information on a dashboard (with real-time data outputs to a dashboard if possible), and also allow downloading of raw data.***

System architecture

To get a bit of a head start, below is the system architecture that teams adopted last year. It's a good way to start, though you are by no means constrained to doing it this way. In any case, you'll have to adapt for this year's needs to work with two partners.

Specifications and Testing

A key team metric is to develop specifications along with a plan to test (or verify) that your system meets those specifications. We'll provide some specifications and system design from last year, but you should refine, update, pivot, and so on. You will be able to consult with staff and with mentors on this.

Given that this is a HW/SW system, we can anticipate specifications falling into the following classes:

Financial
Regulatory
Industrial design
Environmental resistance
Engineering
Security & Privacy
Packaging
Installation and servicing

Remember the two most important things about specifications: 1) have a process, and 2) write them down!. They are subject to update in our iterative process.

Every specification should be backed up with a testing plan for how you will demonstrate that your system achieves that spec. The testing plan should be detailed, quantitative, and verifiable. It is as important as the spec!

Here are some things to think about for different parts:

Financial

We are not selling these systems to our partner, so one may think that cost doesn't matter. But realize that Miami-Dade County has ~7000 bus stops, and the MITOS monitor would love dense sampling and expansion into Cambridge, Somerville, and so on. Our goal in this class is not to manufacture 1000s of systems, but cost it out as if you would be, because that's the a good start for market size (it could be even much bigger!).
Our time to market is dictated by our class schedule.

Regulatory

There's going to be communications here, so some regulatory requirements.
The HW node should be able to withstand outdoor exposure. Remember that Florida and Boston are hot and wet! Our Miami-Dade partners don't require hurricane resistance for this project, though an ultimate deployed device should certainly have that.

Industrial design

Consider how these systems will be mounted. In Miami-Dade it is highly prescribed: there is a [standardized bus stop pole, (see the FAQ), to which it can be attached via metal zip ties or on top. At MIT, we need a variety of mounts: primarily on a tripod, but also to a pole, and so on.
For size and weight, smaller/lighter is better, of course. A handheld device is better than toaster-sized is better than a microwave-sized.

Environmental

Think about that outdoor exposure.

Engineering

Sensors

RH/T should be easy to specify. One consideration is sensor placement to minimize excessive heating up due to solar radiation. Another consideration is sensor placement to make sure the system responds quickly enough.
There are several ways to measure sun exposure.
Likewise, there are several non-contact temperature sensors that you can integrate into your system.
It's up to you if you want to add an air quality sensor, or other additional environmental sensors.
Measuring occupancy is not necessarily easy. Last year teams used WiFi MAC address sniffing. You can use that, or use Bluetooth sniffing (or both), or develop an alternative approach.

Compute

We recommend sticking with the ESP32-C3 that we introduced in lab01. You can go to a different MCU in the ESP32 family if you think you need different specs/cost. You can even go to a different MCU family, or even a SBC, but there will be less help from staff. Up to you!

Comms

All buses have WiFi. WiFi is also ubiqitious on MIT's campus, though you need to find an open network.
Cellular is another option. It adds to BOM and complexity, but makes you able to access more outdoor locations.

Energy management

There's no A/C line voltage around the HW nodes, nor is there a nice 5V USB port to connect to.
There is alot of sun.
And you can use a battery, of course.
Weather changes slowly. Even occupancy is slow from the standpoint of a microcontroller that runs at 160 MHz. So, you can spend most of your time sleeping if you want.

Firmware

What does the MCU need to do in this system? It might need to do more than the MAQS system, since the occupancy, sun exposure, and surface temperature need to be measured.
The MCU will most definitely need to sleep in order to meet energy budget. See previous...

Server & analytics

Since we're setting up a server for MAQS, we recommend using that approach here. But you're not obligated to do so.
Via Swift.ly, you'll each have access to Miami-Dade transit data. You can get a sense of the available data here. But generally, you can expect to have:
- Static information such as the route and schedule of the buses going to your stop, along with stop location
- Real-time information of bus location
Consider how merging information from your HW node with the Swiftly data can be provide more insight to the Miami-Dade team.
There is no local information for the MITOS project, though you could overlay your data on a map.

Web front-end

You'll want to both visualize the data, as well as make it available for use by partners.

Security and Privacy

These systems are going to be deployed in the wild. Residents are important stakeholders here. At MIT, there will be curious students and sometimes members of the public. In Miami-Dade, the transit system is predominantly used by Black and Latino/Hispanic residents, who are also historically marginalized communities.

Packaging, installation, and servicing

How will the HW node be sent to Miami-Dade? Will it be on during the trip?
How will be turned on, set up, and debugged (if needed)?
For our purposes, the HW node doesn't need to last very long (~1 month), but any ultimate system should work for >=3 years without needing servicing.
Similarly, how will the HW node be commisioned for MIT use?

Resources

Lauren Futami's MS thesis on the MITOS systems

MAC address sniffing: