Project Info
Inspiration
🔥 While on the way to CalHacks, we drove past a fire in Oakland Hills that had started just a few hours prior, meters away from I-580. Over the weekend, the fire quickly spread and ended up burning an area of 15 acres, damaging 2 homes and prompting 500 households to evacuate. This served as a harsh reminder that wildfires can and will start anywhere as long as few environmental conditions are met, and can have devastating effects on lives, property, and the environment. The following statistics are from the year 2020[1]. People: Wildfires killed over 30 people in our home state of California. The pollution is set to shave off a year of life expectancy of CA residents in our most polluted counties if the trend continues. Property: We sustained $19b in economic losses due to property damage. Environment: Wildfires have made a significant impact on climate change. It was estimated that the smoke from CA wildfires made up 30% of the state’s greenhouse gas emissions. UChicago also found that “a single year of wildfire emissions is close to double emissions reductions achieved over 16 years.” Right now (as of 10/20, 9:00AM): According to Cal Fire, there are 7 active wildfires that have scorched a total of approx. 120,000 acres. [1] - news.chicago.edu Our Solution: Canary 🐦🚨 Canary is an early wildfire detection system powered by an extensible, low-power, low-cost, low-maintenance sensor network solution. Each sensor in the network is placed in strategic locations in remote forest areas and records environmental data such as temperature and air quality, both of which can be used to detect fires. This data is forwarded through a WiFi link to a centrally-located satellite gateway computer. The gateway computer leverages a Monogoto Satellite NTN (graciously provided by Skylo) and receives all of the incoming sensor data from its local network, which is then relayed to a geostationary satellite. Back on Earth, we have a ground station dashboard that would be used by forest rangers and fire departments that receives the real-time sensor feed. Based on the locations and density of the sensors, we can effectively detect and localize a fire before it gets out of control. What Sets Canary Apart 💡 Current satellite-based solutions include Google’s FireSat and NASA’s GOES satellite network. These systems rely on high-quality imagery to localize the fires, quite literally a ‘top-down’ approach. Google claims it can detect a fire the size of a classroom and notify emergency services in 20 minutes on average, while GOES reports a latency of 3 hours or more. We believe these existing solutions are not effective enough to prevent the disasters that constantly disrupt the lives of California residents as the fires get too big or the latency is too high before we are able to do anything about it. To address these concerns, we propose our ‘bottom-up’ approach, where we can deploy sensor networks on a single forest or area level and then extend them with more sensors and gateway computers as needed. Technology Details 🖥️ Each node in the network is equipped with an Arduino 101 that reads from a Grove temperature sensor. This is wired to an ESP8266 that has a WiFi module to forward the sensor data to the central gateway computer wirelessly. The gateway computer, using the Monogoto board, relays all of the sensor data to the geostationary satellite. On the ground, we have a UDP server running in Google Cloud that receives packets from the satellite and is hooked up to a Streamlit dashboard for data visualization. Challenges and Lessons 🗻 There were two main challenges to this project. Hardware limitations: Our team as a whole is not very experienced with hardware, and setting everything up and getting the different components to talk to each other was difficult. We went through 3 Raspberry Pis, a couple Arduinos, different types of sensors, and even had to fashion our own voltage divider before arriving at the final product. Although it was disheartening at times to deal with these constant failures, knowing that we persevered and stepped out of our comfort zones is fulfilling. Satellite communications: The communication proved to be tricky due to inconsistent timing between sending and receiving the packages. We went through various socket ids and ports to see if there were any patterns to the delays. Through our thorough documentation of steps taken, we were eventually able to recognize a pattern in when the packages were being sent and modify our code accordingly. What’s Next for Canary 🛰️ As we get access to better sensors and gain more experience working with hardware components (especially PCB design), the reliability of our systems will improve. We ran into a fair amount of obstacles with the Monogoto board in particular, but as it was announced as a development kit only a week ago, we have full faith that it will only get better in the future. Our vision is to see Canary used by park services and fire departments in the most remote areas of our beautiful forest landscapes in which our satellite-powered sensor network can overcome the limitations of cellular communication and existing fire detection solutions.
Analysis
View
Metric
- 6
- 5
- 5
- 4
- 1
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- PythonIn code
- StreamlitClaimed
1 of 2 appear in the indexed code. 1 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
11 KB
Source files
8
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
tsai-henry/canary
16 files · 16 KB · @ 79f9af5
Structure
Application logic
10 files · 63%Domain rules, services and shared utilities.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- Python100%
- Markdown0%
Share of indexed source by file size. Binary and vendored files are excluded.
Feature verification
Basic project READMEVerified
README documents the project as 'canary' built at CalHacks 11.0
Claimed on readmehigh confidenceREADME.md:1— README contains only the project name and hackathon name, matching the claim exactly
ESP8266 WiFi module forwards sensor data to gatewayVerified
This is wired to an ESP8266 that has a WiFi module to forward the sensor data to the central gateway computer wirelessly
Claimed on Devposthigh confidenceino/esp/esp.ino:10— WiFiServer on port 8080 with softAP set up, reads Arduino serial data and forwards it to a connected TCP clientrx/rx_esp.py:14— Python client connects to the ESP8266 IP/port and receives the forwarded sensor readings
Gateway computer receives sensor data from local networkVerified
forwarded through a WiFi link to a centrally-located satellite gateway computer
Claimed on Devpostmedium confidencerx/rx_esp.py:22— Writes received child sensor data to sensor_data/child1.txtrx/rx_hub.py:19— Writes hub sensor serial data to sensor_data/hub.txt
Gateway relays sensor data to satellite via Monogoto/Skylo NTN boardCode-supported
The gateway computer, using the Monogoto board, relays all of the sensor data to the geostationary satellite
Claimed on Devpostlow confidenceskylo/python_at.py:42— Sends AT commands over serial to a Skylo NTN module and has a send_udp method to transmit a message via satellite UDP socket
GPS positioning for satellite communicationCode-supported
Technology details imply satellite positioning is configured for NTN communication
Claimed on Devpostlow confidenceskylo/python_at.py:43— AT%NTNCFG command sets latitude/longitude/altitude for the Skylo module's satellite positioning
Sensor node reads temperature via Arduino + Grove sensorCode-supported
Each node in the network is equipped with an Arduino 101 that reads from a Grove temperature sensor
Claimed on Devpostmedium confidenceino/child_sensor/child_sensor.ino:12— analogRead(0) reads a voltage and converts to a temp value, sent over Serial1ino/hub_sensor/hub_sensor.ino:12— Same analog temperature read pattern for the hub sensor node
Streamlit dashboard for real-time sensor data visualizationCode-supported
hooked up to a Streamlit dashboard for data visualization
Claimed on Devpostlow confidencestreamlit_stacey.py:19— Streamlit app renders a temperature chart with matplotlib, but the plotted values are np.random.uniform() mock data, not data read from the UDP server output or sensor_data files
UDP server in Google Cloud receives satellite packetsCode-supported
a UDP server running in Google Cloud that receives packets from the satellite
Claimed on Devpostlow confidenceskylo/udp_server.py:4— Basic UDP server bound to 0.0.0.0:51820 that receives and echoes packetsskylo/udp_pandas_server.py:20— UDP server variant that parses source tag and stores packets in a pandas DataFrame, but contains a syntax error (missing colon on the if statement) making the file not runnable as-is
Extensible sensor network with fire localization by sensor densityClaimed only
Based on the locations and density of the sensors, we can effectively detect and localize a fire before it gets out of control
Claimed on Devposthigh confidenceMonogoto Satellite NTN and Murata hardware integrationClaimed only
leverages a Monogoto Satellite NTN... Built with monogoto, murata
Claimed on Devpostmedium confidence
An AI agent derived these features from the project’s Devpost page and readme, then searched the code for each one. Verified features are backed by cited code; claimed-only features had no supporting code, which is not by itself proof a feature is missing.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.