About Thermominator

Thermominator is a campus heat monitor: a fleet of sensors + a map-first dashboard that helps you pick cooler paths and avoid hot spots.

The team

team2

Built by MIT 6.9000 Team 2.

Sensors

Andy, Sydney, Ann

PCBs

Jonatan, Justin, Annie

Power

Ann, Sydney

Comms

Tori

Firmware

Annie, Jonatan, Sydney, Andy

Server

Cole

Industrial design

Justin, Cole

Class context

MIT 6.9000

This project was built for MIT 6.9000 (Spring 2026). The purpose of the system is to understand the local heat experience on different parts of the MIT campus.

Brian Goldberg’s presentation from Lecture 2 is available to review.

Deliverable

An end-to-end system: devices → backend → database → map UI

Constraints

Low-friction deployment • clear UX • reliable data ingest

Constraints & requirements

from Lecture 2

* → *** indicates level of importance.

  • (***) Accurately measure exterior air temperature and humidity while walking, with dynamics appropriate for the use case.
  • (*) Measure sun exposure while walking, with dynamics appropriate for the use case.
  • (***) Very small, portable, and easily affixed to a backpack (or similar) for walking around.
  • (**) Report faults (battery failure, mechanical destruction, etc.).
  • (***) Inexpensive (COGS ≤ $20 USD).
  • (***) Electronics can be fabricated and assembled by JLCPCB.
  • (***) Environmental data from each sensor node connects to the location where it was obtained.
  • (***) Maintain privacy.
  • (***) Battery lifetime of 3 months or at least 24+ hours between recharging.
  • (***) Rugged for summertime Boston-area environment (heat, rain) + typical jostling during transit.
  • (**) Transit environmental data can be connected to spot measurements of the person’s body temperature.
  • (***) Multiple systems can be used simultaneously.
  • (***) Present information on a dashboard in real-time or near real-time, and allow downloading raw data.

How we solved it

system overview

We treated this as a sensing → interpretation → decision problem. A small fleet of devices collects local conditions, and the dashboard turns that into a map you can act on (where to avoid, where to go), with time controls to compare “now” vs earlier.

Sensing

Distributed readings across campus areas, updated continuously.

Spatial model

Campus is divided into polygons (“sectors”) so we can aggregate and compare regions.

Visualization

Map-first UI with relative hot/cool cues and drill-down on click.

Operations

Admin workflow to keep the fleet healthy and the data trustworthy.

Technical details (API layout, DB schema, seeding, etc.) live in the linked docs below so this page stays readable.

Design docs

links

Add links here for your writeup and presentation. These can point to Figma, PDFs, or repo files. There is also a FAQ that might be useful.

Figma
UI flows + block diagrams. Add link
Architecture diagram
Server/API/DB overview. Add link
PRD / Goals
Problem statement + success metrics. Add link
Roadmap
Milestones and next steps. View image
FAQ
Common questions and operational notes. Add link