Valerie Project

This is your landing page for information related to the semester project with Miami-Dade County, which we're calling: Valerie.

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

You can find information about the beta.

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

Succesful teams will lead to succesful projects. We'll help: we have online resources and our colleagues in Sloan to give lectures and assignments on 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 EX01. 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.

You'll have a team workspace in A365 for board designs.

Team coordination

Starting in Lab02, there will be a weekly meeting with the team and at least one staff member to check in. 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 March 2 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.
• Mentor liaison. One person should be the point of contact to the Miami-Dade mentors.

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 Miami-Dade partners. 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.

You can reach the mentors at efi-miamidade-mentors@mit.edu. On this mailing list are:

• Carlos Cruz-Casas, Chief Innovation Officer
• Linda Morris, Chief of Service Planning & Scheduling
• Raonel Rodriguez, Manager of Passenger Amenities
• Toni Phansang, Systems Support Manager
• Boon-choo Tan, Systems Support Manager
• Jarice Rodriguez, Principal Planner at the Office of Innovation
• Julian Guevara, Municipal Manager at the Office of Innovation
• Marta Viciedo, Transit Alliance’s Interim Executive Director
• Nicholas Duran, Transit Alliance's Advocacy Manager
• 6.900 Staff

The mentor liaison is the only person on the team who is allowed to email the Miami-Dade mentor list. That person should craft emails with questions.

You can only send one email to them mentors each week.

We strongly recommend having staff take a look at emails before sending, so we can see if there are any questions we know answers to, or that need revising.

We have a running FAQ with questions submitted by Teams and the answers.

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.

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:

1. It should measure the "heat experience" at each bus stop, at least temperature and humidity, but also could include air quality.***
2. It should be able to measure how many people are waiting, and for how long.***
3. It should operate without being connected to line voltage. ***
4. It should be installable by a technician, and should be easy to set up.***
5. It should not be too expensive. *
6. Data from a sensor node should be able to be tied to a location.***
7. It should maintain privacy. ***
8. It should be rugged and able to withstand shipping, setup, and operation in the Miami-Dade environment. ***
9. Multiple systems should be able to be used simultaneously. ***
10. 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.

In contrast to MILO, where we provided both requirements and specifications, here we'll provide only barebones specifications. It's up to the team to develop specifications! You will be able to consult with staff and with mentors from Miami-Dade county 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

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. Not all of them need monitoring, but if you can create a cost-effective solution, there is the chance to use these systems broadly, and even consider having them in other cities.

• 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 experiences hurricanes!

Industrial design

• Consider how it will be mounted to the bus stop. Now, there are many different bus stops: everything from a pole to a fancy shelter. The need is greater for the pole (which is more subject to the elements) than the fancy shelter, which already provides some shade. Our partners recommend a system that can be fastened with metal zip ties.
• For size and weight, smaller/lighter is better, of course. But how big is too big?

Environmental

• Think about that outdoor exposure.

Engineering

Sensors

• RH/T should be easy to specify.
• It's up to you if you want to add additional environmental sensors.
• Measuring bus station occupancy is not necessarily easy. It's up to each team to figure out how to do this.

Compute

• We recommend sticking with the ESP32-C3 that we used for MILO. You can go to a different MCU or MCU family, or even a SBC, but there will be less help from staff. Up to you!

Comms

• All buses have WiFi.
• You could also consider cellular. Sometimes cellular is more difficult to set up.

Energy management

• There's no A/C line voltage at these stops, nor is there a nice 5V USB port to connect to.
• There is alot of sun.
• And you can use a battery, of course.

Firmware

• What does the MCU need to do in this system? It might need to do more than the MILO system, since the occupancy needs to be measured.
• The MCU will most definitely need to sleep in order to meet energy budget.

Server & analytics

• Since we're setting up a server for MILO, 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.

Web front-end

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

Security and Privacy

• These systems are going to be deployed in the wild. Residents are important stakeholders here. 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.