![](./images/logo.png width="500" margin-left="5px") Project Overview =============================================================================== ![](./images/fire.jpg width="800") Forest Fires prove a serious danger to life and property. Since the 1970s, the frequency of forest fires in the western half of the United States has increased nearly 400%. Raging fires torch over 10,000,000 acres, causing an estimated $347.8 billion in damage from destruction to homes, buildings, and the ecosystem. The US National Forest Service spends $2.9 billion annually fighting forest fires. Every year, 15,000 people in the US die from health effects related to wildfires. In order to defeat this tremendous threat to lives, livelihoods, and the ecosystem, we need better methods of detecting at-risk areas for forest fires. Ember Alerts proves a cost-effective, scalable, and efficient solution to providing superior insights into current at-risk forest areas. With quicker detection of danger areas, we hope to provide local firefighters, park rangers, and concerned citizens with greater real-time analysis of forest fire risk. This will allow individuals to resolve dangerous areas, mitigate potential dangers, and, if necessary, more quickly evacuate. [1] ![Figure [block]: Functional diagram of Ember Alerts system. 'Embedded Systems' represent deployed Ember Alerts modules, while each 'Data Layer' is a different data visualization mode accessible via the dashboard.](./images/block.png width="600") Hardware =============================================================================== ![Figure [hardware]: Hardware overview of an Ember Alerts module.](./images/hardware.png width="800") As used in class, all additional sensors in an Ember Alerts module interface through an ESP32 microcontroller with built-in wifi capabilities. Temperature & Humidity Sensor --------------------- Both temperature and humidity are crucial to the determination of fire risk in any region. We chose to utilize the Adafruit Si7021 sensor to collect these values. According to the manufacturer, the sensor is extremely power efficient, using 150µA when active and only 60nA on standby. Furthermore, with this low power profile, the Adafruit Si7021 has an extraordinary range and precision for our applications, detecting 0% to 80% relative humidity (max deviation ±3%) and -10℃ to 85℃ (max deviation ±0.4℃). [2] Smoke Detector --------------------- A smoke sensor is not a critical element of the fire risk assessment functionality of Ember Alerts. Rather, it allows for a network of these modules to identify during times of high fire risk when a fire has, in fact, broken out. To provide this functionality, we used a Willwin MQ2 smoke and gas sensor. Using silicon dioxide gas-sensitive material, this sensor detects levels of both smoke and flammable gasses. [3] Fire Risk Feedback =============================================================================== Dashboard Overview --------------------- ![Figure [dash]: Sample point plotted on the dashboard UI.](./images/dash.png width="500") A clear and usable visualization tool is imperative to the success of Ember Alerts. We used matplotlib to visualize a map of the Boston area which can be overlayed to showcase different fire risk factors. The dashboard can be toggled in order to view temperature, humidity, smoke, burning index, spread component, and ignition component. The overlaid map can also be changed in order to best serve the needs of user. This can easily be used by fire prevention services in order to map the network of Ember Alerts modules throughout a forest, identify high-risk areas, and even track the spread of a fire. Risk Assesment --------------------- ![Figure [equation]: Structural overview of National Fire Danger Rating System equation to calculate fire risk.](./images/nfdrs_eq.png width="600") Sensor | Weather API | Hardcoded -------|------|---------- Relative Humidity | Wind Speed | Fuel Model Type Temperature | Status of Weather | Live Vegetation Cycle GPS Location | | Climate Class Slope Class | |Duration of Precipitation [Table [inputs]: Overview of where the inputs to the NFDRS calculation come from in each Ember Alerts module.] In order to determine the risk of a forest fire, we decided to use the National Forest Danger Rating System (NFDRS) implemented by the United States National Forest Service. Given several parameters such as weather, humidity, temperature, and vegetation in the region, the NFDRS computes 4 major numerical outputs, along with a classification of fire danger. Ignition Component: the probability that a fire will result if a firebrand is introduced into this site. Energy Release Component: the available energy, measured in British Thermal Units per square feet, at the flaming front of the fire. Spread Component: Forward rate of spread of the flaming front of the fire, measured in feet per minute. Burning Index: 10 times the predicted flame length, in feet. This is the main component used to calculated fire classification. Classification of fire risk as one of, in order of increasing danger: {LOW, MODERATE, HIGH, SEVERE, EXTREME}. ![Figure [graph]: Fire risk characterization based upon Spread Component, Energy Release Componenet, and Burning Index.](./images/nfdrs_rating.png width="650") Given several parameters such as weather, temperature, humidity, and fuel model characteristics, our state-of-the-art fire risk-determination algorithm provides all 4 crucial numerical values, along with a classification of the risk. These values can be used by Park Rangers or Firefighters to locate risky areas, determine specific contributors to the risk, and, hopefully, take action to remove or mitigate the dangers of a forest fire. Power Management =============================================================================== For the purposes of this project, we theoretically assumed battery usage although we used wall power for demonstration purposes. Each module that sits in nature will be powered by its own battery. Obviously, it’s important that these modules require as little human intervention as possible to maintain. Part of the delivery strategy for Ember Alerts is to scatter these modules over large swathes of land in order to gain a better understanding of holistic forest health. These modules are also very small. Therefore, it’s highly likely that human operators will have a hard time locating each module in order to replace batteries and do other maintenance. That reason alone is enough to justify mental effort toward the creation of a detailed power management strategy in order to make Ember Alerts feasible. For the purposes of this discussion, we are going to assume that each module needs to be able to operate for an entire year without human maintenance. That is on the absolute low end of what is required of each module. The ESP32 is a relatively power-hungry device compared to other microcontrollers. Nevertheless, the ESP32 has 5 different configurable power modes that it can switch into in order to maximize energy usage efficiency. The two modes that we will use are Active mode and Hibernation mode. During Active mode, the Wifi module, processing cores, and Bluetooth module are all on. We only tested an Ember Alert module sending measurements over Wifi. During Active mode, we anticipate wanting to make and deliver a measurement to the server once every hour. Based on empirical data, it takes about 2 seconds for our module to take a measurement and send a POST request to the server database. That means that over 1 hour, the ESP32 will be in Active mode for 2 seconds. The rest of that time, it will be in Hibernation mode. Hibernation mode means that almost every inner module and core is turned off, including the ULP-coprocessor and Radio. The only thing on the ESP32 that remains on during Hibernation mode is the RTC timer and a few of the RTC GPIOS. Basically, this is the bare minimum required to wake the ESP32 up after a predetermined amount of time. Over a 1 hour cycle, the ESP32 will spend 3,598 seconds in Hibernation mode before it wakes up, takes and sends measurements, and goes back into Hibernation. While in Active mode, based on empirical data that our group took, we were consuming about 285 milliAmps. While in Hibernation mode, we found the ESP32 consumed about 2 microAmps. To be safe, for the rest of our calculations, we assumed a power consumption of 0.160 milliAmps over a 1 hour period. That gave us an average of 3.848 milliAmps per day or 1,404.5 milliAmps per year. That means our system could run with a regular AA battery for approximately 1.7 years. We would need to factor in battery inefficiencies to get a more granular estimation but the strategy we have outlined for taking and sending measurements and oscillating between different ESP32 modes makes Ember Alerts feasible with inexpensive batteries. Implementation =============================================================================== Server Side --------------------- ``````````````````````````````````````````````` dashboard.py ``````````````````````````````````````````````` - Main function called by Operator - Collects data from Sensor Database; runs computational algorithm on the acquired data - Plots output of algorithm on top of map of Boston; produces 6 plots: Humidity, Temperature, Smoke, Burning Index, Ignition Component, and Spread Component - Main Data Visualization script to allow user to determine risk of fires ``````````````````````````````````````````````` heatmap.py ``````````````````````````````````````````````` ``````````````````````````````````````````````` boston_pic.png ``````````````````````````````````````````````` - Contains a screenshot of Google Maps of Boston and the outlying areas - Overlaid with data from computations and sensor to allow the user to better understand the location of reported geographic coordinates ``````````````````````````````````````````````` preliminary_calcs.py ``````````````````````````````````````````````` - Conducts preliminary calculations for NFDRS workflow - These calculations convert gathered environmental parameters into intermediate values for computation of the final four values for fire risk assessment ``````````````````````````````````````````````` dead_fuel_models.py ``````````````````````````````````````````````` - Calculates the intermediate dead fuel model given environmental parameters - Key output values such as dead-fuel moisture for 1-1000hr used in computations for the final four numerical values ``````````````````````````````````````````````` final_four_calcs.py ``````````````````````````````````````````````` - Computes the most significant four values for the National Fire Danger Rating System: Burning Index, Energy Release Component, Ignition Component, and Spread Component ``````````````````````````````````````````````` Python def ignition_component(master_dict): """ Calculates the ignition component. Numerically equivalent the probability that a fire will result if a firebrand is introduced into a fuel. @params: master_dict (dict): contains all the variables from preliminary calcualtions and associated evnironmental parameters @returns: ignition_component: probability that a firebrand will produce a successful fire start in dead, fine fuels, P(I) """ def spread_component(md): """ Calculates the spread component of the fire given environmental parameters. Numerically equivalent to the forward rate of spread in feet per minute @params: master_dict (dict): contains all the variables from preliminary calcualtions and associated evnironmental parameters @returns: spread_component: numerical value for forward rate of spread of fire in feet per minute. """ def energy_release_component(md): """ Calculates the the energy release component. Numerically equivalent to the availability energy (BTU) per unit area (square foot) within the flaming front at the head of a fire. @params: master_dict (dict): contains all the variables from preliminary calcualtions and associated evnironmental parameters @returns: energy_release_component: numerical value for available energy per unit area measured in BTU per unit area. """ def burning_index(master_dict): """ Calculates the burning index of a fire given environmental parameters. Numerically equivalent to 10 times the predicted flame length, in feet. @ params: master_dict (dict): contains all the variables from preliminary calcualtions and associated evnironmental parameters @returns: burning_index: numerical value for 10*predicted flame length, in feet. This is the primary value used to determine fire risk classification. """ ``````````````````````````````````````````````` ``````````````````````````````````````````````` fuel_model_appendix.py ``````````````````````````````````````````````` ``````````````````````````````````````````````` master_danger_calc.py ``````````````````````````````````````````````` - Communicates with Weather API to gather necessary data - Builds computational workflow by calling all prior algorithm-related scripts - Allows for one, single interface used by all data visualization scripts. ``````````````````````````````````````````````` Python def calc_danger_ratings(relative_humidity, temp, lat, lon): ### Possibly add an extra parameter for fuel model surrounding areas """ Performs all 4 numerical calculations for fire risk assessment. Concludes with a classification of risk according to National Fire Danger Rating System. @params: relative_humidity (float): humidity measured by sensor. Expressed as percentage measure between 0 and 100. temp (float): temperature measured by sensor. Expressed in degrees Celcius lat (float): GPS latitude of sensor. lon (float): GPS longitude of sensor. @returns: return_dict (dict): Contains all four numerical calculations and classification. Format is: {"ignition component": X (float), "burning index": X (float), "spread component": X (float), "energy release component": X (float), "classification": "X" (string)} """ ``````````````````````````````````````````````` ``````````````````````````````````````````````` fuel_model_appendix.py ``````````````````````````````````````````````` - Translates the appendix of the NFDRS paper into Python - Necessary for creating the hard-coded environmental parameters to determine fuel models - Creates the master dictionary to be used in all other computations Device Side --------------------- ``````````````````````````````````````````````` master.ino ``````````````````````````````````````````````` - Executes all device side capabilities - Functions include sensor readings ``````````````````````````````````````````````` C void loop() { /*----- * Takes measurements for smoke, humidity, temperature, latitude, and longitude. * Then, POSTs all those measurements to the database on our server for higher-level interpretation. */ } void extractGNRMC(){ /*----- * This function goes through the various forms of GPS our module outputs and separates the GNRMC reading. * GNRMC specifically contains time, date, position, track made good, and speed data. */ } void extract(char* data_array){ /*----- * This function takes in a character array from extractGNRMC() and separates the different data elements within that * reading into the classes they belong to. Here we separate latitude, longitude, time, date, etc. */ } ``````````````````````````````````````````````` Design Challenges =============================================================================== Fire Risk Computation --------------------- Choosing which algorithm/computational process to use to determine fire risk was the most substantial design decision made. There were numerous options available; in particular, many new methods using AI analysis of satellite imagery proved promising. However, in order to make the most of the embedded system approach, we decided to use the National Forest Service Fire Danger Rating System, which was developed in the early 1970s. This tried and true method has been the back-bone of the US National Forest Service’s method of detecting fire risk for nearly 50 years. Overall, our sensor approach allows us to incorporate this tested algorithm with real-time analytics, a scalable network of sensors, and precise data collection Hardware --------------------- Even before choosing the algorithm, we choose parts for our embedded system - the humidity, temperature, and smoke sensors. Preliminary research showed that these pieces of data were highly correlated with fire risk. As we delved deeper into research, we discovered that nearly every required environmental parameter was covered by these sensors! Persistent Data Storage --------------------- Naturally, a Database seemed the best option to ensure persistent access to data collected by the sensors. However, as an Ember Alerts module network were to grow, external storage could become necessary. This dependency is largely dependent upon the user’s desire regarding the storage of historical data. Future Work =============================================================================== While substantial effort was put into Ember Alerts over the past 5 weeks, the product is far from fully finished. As such, there are a number of potential areas of future development. First, we ought to seek to minimize the number of hard-coded parameters. As shown above, many of the abstract concepts relating to fire risk remain hard-coded in our algorithm. While these hard-coded values may work for certain regions, ie implemented for springtime in the Northeastern United States, they ultimate prove a tremendous obstacle to overall scalability. Early on, we attempted to use an Arduino camera as part of our sensor setup. Numerous problems, including an extremely high use of power and module durability in variable weather conditions, ultimately forced us to abandon using the camera on our final Ember Alerts sensor. However, a camera would prove useful for determining the stage of live vegetation to discern a live fuel model, as well as for us to determine the type of dead fuel. Applying ImageNet on top of images gathered by the camera would allow us to classify the type of vegetative growth, allowing more specific calculations using tailored environmental parameters. While the climate class tends to be hard-coded based on the sensor location, we could improve our estimation of duration of precipitation over the last 24 hours. One possible method is to use a database of results from the Weather API in order to maintain persistent data access. Meet the Team! =============================================================================== Wilbur "zaaa" Li --------------------- Aspiring pizza maker, Army ROTC Cadet, fearless Platoon Leader, and political mastermind. Sam "josef" Dorchuck --------------------- Navy (ew) ROTC Cadet Ian "italian stallion" Miller --------------------- Army ROTC Cadet?, First Searget? (he doesn't have a rank) Rishi "standby" Shah --------------------- Back-up Battalion Commander References =============================================================================== 1. https://www.usnews.com/news/data-mine/articles/2018-08-01/wildfires-are-getting-worse-and-more-costly-every-year 2. https://cdn-learn.adafruit.com/assets/assets/000/035/931/original/Support_Documents_TechnicalDocs_Si7021-A20.pdf 3. https://www.amazon.com/Willwin-Butane-Methane-Detector-Arduino/dp/B0778NQ5JK/ref=asc_df_B0778NQ5JK/ 4. https://www.fs.fed.us/psw/publications/documents/psw_gtr082/psw_gtr082.pdf 5. https://www.mesonet.org/index.php/agriculture/map/range_forest/fire_danger/burning_index1