What's on this page

Here we provide guidance that will be useful as you go through your project this term

• Milestones and deliverables
• Specifications and testing
• Questions for our partners

Milestones and deliverables

An important part of managing a long-term team project is effective time management. The purpose of the milestones and deliverables is to keep you on track to avoid a heroic effort right before reviews.

What's a milestone? What's a deliverable?

A milestone is accomplishing a particular task in the evolution of the project. A deliverable is how you demonstrate that you have accomplished that task.

For example, one requirement of some term projects is to measure the local weather, let's say through temperature and relative humidity measurement.

From that requirement comes a set of specifications, for example you may decide that you need to measure temperature in the range of -20 deg C to 50 deg C, with +/- 2 deg C accuracy (note, these are probably not going to be your actual specs!).

Next, you have to figure out how to implement that functionality, and then test it. So you may decide that it will take you one week to get the temperature sensing up-and-running, and then you will spend a week testing that outdoors.

So already you have a set of steps, and sample milestones and deliverables for this part of the project could be:

You can see that some tasks depend on prior tasks. For example, you can't test the temperature sensing until you have the sensor up-and-running, which in turn requires some hardware (ESP32 + temp sensor, maybe battery) and some code. Think about staging milestones and deliverables based on dependencies.

Also not displayed up here is how you actually run the testing plan. That aspect will be in your specifications document. But the testing plan is critical. For example:

Will you measure this indoors or outdoors? In either case, how will you generate all these temperatures? If you decide to put in a fridge or freezer, will you run the ESP32 battery-powered or not? And will you store the data on the ESP32 or send it to the cloud? If you send it to the cloud, what happens if wifi does not work inside the fridge?

Lots of details to work through!

Milestones & deliverables table

We've created a milestones table and put it in your Google Drive folder. This is your central source for everything you're doing over time.

Updating milestones & deliverables

You can and will need to adjust the table as your project evolves, and based on the specifics of your project. We've crafted the table to help you get off to a strong start, but ultimately you are the ones that need to deliver.

Every week near the end of your team meeting, you should present finalized milestones & deliverables for the upcoming week. You can edit the upcoming milestones and adjust the schedule, but you need to hit the pink DR1, DR2, and Final update milestones.

You cannot update the coming week's milestones after your team meeting.

Creating good milestones and deliverables

Well-written milestones and deliverables are easy to interpret. For example, here is a poorly written milestone and deliverable:

This is not a useful milestone because it is really a task (what you'll be doing) rather than a milestone (what you'll accomplish). One could "do some" research for 5 minutes or 5 hours, and make various amounts of progress. In addition, no deliverable is proposed. Looking at some web pages is not a good deliverable! Here is a better-written milestone and deliverable:

Your project will need to have a number of milestones and deliverables each week. This is because you'll want to break down your system development into parts that each teammate can work on, and you want each teammate to have responsibilities each week.

Evaluating and grading milestones and deliverables

Each week we will evaluate the set of milestones and deliverables and assign individual and team grades for them. This will not occur in real-time during the mentor meetings. We'll do it asynchronously afterward.

Each deliverable should be linked to a document, video, image, code repo, etc. that we can use to easily verify its completion. There's a column in the milestones & deliverables table to provide links to each deliverable.

For example, if your deliverable is:

• Updating a document: link to the relevant section of the document
• Demonstrating some measurement results: link to plots or videos of those results in your google drive
• Website functionality: link to a screen-capture video of you demonstrating that functionality
• Succesful 3D print: link to image or video of print on bench

And so on...

We will grade each deliverable on a 1..4 scale:

• 4: conclusively meets the milestone
• 3: mostly but not conclusively meets milestone
• 2: gets part of the way there
• 1: total fail, did not do, did not submit

60% of each milestone grade will go to the entire team, and 40% to the in-charge person.

Each team member needs to be in-charge of an approximately similar number of milestones over the course of the project, with a spread of two milestones, aka someone may be in charge of 9 milestone and someone else in charge of 7.

Peer evaluations

Every other week you will evaluate your team members and yourself. Although this is a graded component, the primary goal is to identify any issues early on so the team can adjust.

Specifications and testing

Your Google Drive folder includes a draft specifications & testing document. This is your central source of truth about your system.

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.

We've partially filled out your specifications and testing document. You'll see that each specification has a unique ID, so it is easy to refer to elsewhere. And each test has is associated with one (or more) spec IDs.

As you go thru the specifications & testing document, here are some things to consider, no matter which project you are doing.

Financial

• We are not selling these systems to our partners, so one may think that cost doesn't matter. But different projects have different cost constraints, which will affect their ultimate utility.

• Our time to market is dictated by our class schedule.

Industrial design & environmental

• The HW node should be able to withstand outdoor exposure. Boston is hot and wet during the summer! And cold and snowy in winter. Sometimes we have rain, fog, sleet, and so on.
• Consider how these systems will be mounted or attached.
• For size and weight, smaller/lighter is better, of course. A handheld device is better than toaster-sized is better than a microwave-sized.

Engineering

Sensors

This depends alot on the project. Here are some thoughts that are relevant for different projects.

Environmental

• RH/T should be easy to specify and measure...but really hard to measure accurately. There's a reason that professional-grade weather stations cost $1000s of dollars. It's because it's really hard to accurately measure air temperature. Usually people use an elaborate (expensive) shield to do this. But you can't afford that. You can buy, print, or fabricate inexpensive shields. Or maybe you can do something with a mix of HW and SW to get good accuracy? This company has a way of compensating for solar radiation using sensors and data science, as described in this video. Of course, if your system is supposed to be really small or really inexpensive (or both), you may have limited options.
• There are several ways to measure sun exposure. Your phone does this...
• Likewise, there are several non-contact temperature sensors that you can integrate into your system if you want to measure surface temperature. That said, these are pricey, so you'll have to decide whether it's worth the BOM.
• It's always good to remember that there's a temperature sensor on your ESP32C3, so you can measure internal temperature relatively easy.

Objects

• There are several ways to detect relatively large objects moving past a fixed location, like an opening or a bike lane. For example, check out this doc, or Numina for inspiration.
• You may want to consider ultrasound sensors or mmwave sensors. Be careful with sensors that use light, like PIR or time-of-flight sensors, as they can have issues outdoors.
• Visible-light cameras are appealing because they move the detection challenge into software, but note that they can consume alot of power, and that there can be privacy implications. IR cameras are better for privacy but more expensive.
• Bike lanes have prescribed dimenions. You'll want to become familiar with them if that's your project.
• You can't drill into the asphalt. Sorry, no buried inductive loops.

Location

• For a fixed object, the simplest approach is to enter coordinates into a database when provisioning a system. Just make sure it is possible to change the location in your database!
• GPS modules are one way to know where you are. But they are fairly expensive and can consume a fair amount of power.
• If you don't want to purchase a GPS module, maybe you can access the one on the phone that most people carry around with them anyway.
• Or, it turns out that organizations have mapped out WiFi Access Points, and you can maybe use these to triangulate (trilaterate, if we want to be accurate) your location.

Compute

• You should stick with the ESP32 ecosystem, but that doesn't necessarily mean the ESP32C3 is the right MCU. There is an entire family of ESP32 MCUs that you can choose from, each with its own features. Take a look!

Comms

• WiFi is present everywhere on campus, sort of. Sometimes it's hard to get at in the nooks and crannies (or in lab, lol). If using WiFi, it's a good idea to scan for APs and deliberately pick the strongest one.
• Off-campus, WiFi can't be relied on, unless you know that there is an open network wherever your system must be.
• Cellular is another option. It adds to BOM and complexity, but makes you able to access basically any location.
• LoRa is another option for low-power long-distance comms. Super low power and long distance. But note that due to the datarate limitations, it can't do OTA firmware updates.
• No matter what, it's a very good idea to have a strategy in your firmware to deal with the inevitable communication failures.

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 sun, but not in all locations and at all times.
• And you can use a battery, of course. Sometimes a battery is all you need. Just make sure it can be recharged or easily changed.
• The key to maximizing system lifetime is to sleep as much as possible.

Firmware

• What does the MCU need to do in this system? You'll want to architect the firmware so that it is easy for team members to work on different sections, easy to debug, and so on.
• You can architect the firmware using state machines, RTOS threads, whatever you like. But make sure there is an architecture early on.
• That firmware architecture should include not just standard operation, but provisioning, dealing with errors/failures, debug modes, etc.
• Watchdogs are your friend.
• Debugging is much easier if you have a way of logging what the system is doing. You can use onboard memory/storage, external flash, SD card, sending to server, etc. All that takes storage and energy.

Server & analytics

• We're setting up a server in the psets, and we'll provide you with your own machine to use for the project. You should use that machine. In fact, you must use the server we give you.
• It will be useful to overlay your data on a map.
• You'll want to both visualize the data, as well as make it available for use by partners.
• Look at example dashboards online to get inspiration.

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.
• Outside MIT, how long will a box mounted at waist height last in the City of Cambridge? Not sure. Some prior systems have encountered catastrophic failure, others have stuck around for months. Mounting something out of the way is one approach, but it might make measurement more challenging.
• The City of Cambridge has a surveillance ordinance. Your project is ok because it's experimental. But keep in mind the community and their acceptance as you consider different designs.

Installation, provisioning, and servicing

• How will the HW node be installed, turned on, commisioned, and debugged (which will certainly be needed)?
• We'd like to set up the systems in May and leave them out till the winter, ideally without someone needing to attend to it.

Questions for our partners

Translating from requirements to specifications to an actual design will almost certainly need help from staff, and from our 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.

If you have questions for our partners, formulate them into a single email and send to the 6.900-staff. Sometimes we know the answers, and if not we'll send over to our partners for input.