Smart Firefighter Helmet

Project Description

Firefighters often find themselves in dangerous situations where they must make split second decisions based on what they perceive to be a worthwhile risk. Often this risk assessment is done with little to no knowledge of the real dangers of pursuing a specific task.

With our design, we aim to give firefighters a better idea of what risk they face when making a split-second decision. Additionally, we want someone outside of the dangerous situation to have an idea of where the firefighter is and if they are still in operational condition so that those on the outside can act accordingly with medical or additional fire fighter assistance.

Engineering Design Specification

Design Problem

Firefighters often find themselves in dangerous situations where they must make split second decisions based on what they perceive to be a worthwhile risk. Often this risk assessment is done with little to no knowledge of the real dangers of pursuing a specific task. Firefighters are also responsible for their own safety, and we want to change that in a way that makes being a Firefighter safer by having other people monitor their environment and state as well.

Intended Purpose

With our design, we aim to give firefighters a better idea of what risk they face when making a split-second decision. Additionally, we want someone outside of the dangerous situation to have an idea of where the firefighter is and if they are still in operational condition so that those on the outside can act accordingly with medical or additional fire fighter assistance.

Unintended Purpose

Since this project is to be used by firefighters, it is not for public use. We expect this to primarily be for bigger fire departments as the cost is expensive. So, we do not intend small, volunteer fire stations to own these, however, we do not want to discourage any fire department from using the technology to their advantage. That being said, these will primarily be reserved for large fire departments in cities where fires tend to be more dangerous in close quarters.

Special Features

We will be implementing a series of sensors including gyroscope, carbon monoxide sensor, temperature, and location detection, among others. Additionally, we want this information to be available to the firefighter and the third party aiding the firefighter onsite. The recorded information will be viewed in a dashboard format, so the data can be easily read by someone outside of the situation.

Customer Requirements

Functional Performance

The indoor sensor will reveal the exact location of the firefighter. Furthermore, with the gyroscope included, it will ensure that the firefighter is still moving. Also, the gas detector sensor will detect any common toxic gases in the environment. All this information will be displayed, in real time, to ensure the firefighter’s safety. In addition, the helmet will provide cooling with semiconductor refrigeration tablets to reduce the likelihood of heat exhaustion.

Operating Environment

The operating environment will most likely be in intensive heat. The sensors affixed to the helmet should be able to operate in hot temperatures. The maximum temperature that these sensors can operate would be at about 400°F. Since the sensors will be integrated into the firefighter helmet, the sensors will be constructed in a compact size that should not hinder the wearer. In other words, the sensors will operate efficiently in a compact size.

Geometrics

The geometrics of this project will be small-scale. Eventually, we want it to be scaled down enough that it should fit in the firefighter's helmet or even on a necklace if it allows for enough space for our device. For the moment, the project will be compact enough that it does not hinder the wearers' movement. If the project is too large for the helmet, we may integrate it into torso gear.

Maintenance, repair, and retirement

For Maintenance, the gyroscope, barometric pressure, and accelerometer will need to be properly calibrated. Furthermore, the gas sensor and the location module might need some calibration after some time. For retirement, the environmental sensors should last 3 years before replacement. The GPS location boards will need to be replaced every 2 years depending on usage. The rest of the sensors should be able to last longer than the environmental sensors.

Reliability and Robustness

The design of the project should be able to withstand strong impacts without the sensors taking damage. As a result, the data gathered by the sensor should be as accurate as possible regardless of the conditions. Furthermore, no failure should occur when operating at maximum temperatures. We intend on doing this with proper casing and storing part of the device under turnout gear to keep it at reasonable temperatures. The barometric pressure sensor can be replaced with a more reliable sensor like the BME680. Our current barometric sensor is not reliable.

Safety

To prevent overheating the materials, we will need heat-resistant materials to encase our sensors in. However, since most heat-resistant materials are expensive, our design will be 3D printed for demonstration.

Ease of Use

This project will be easy to use. Firefighters should be able to use this project with minimal training. The only user interaction will be the on and off switch. The third party will need some training for reading the display values of the different sensors. Furthermore, the third party will need to understand how to read the specific location of the individual firefighter.

Human Factor

If the sensors are failing, it should be easy to calibrate or replace them. Not much interaction with the device is needed. While the device is on, the sensors should not be removed.

Appearance

Since we want this project to be integrated into the helmet, we will make it small enough that it will fit easily on the outside. We also considered integrating it on the inside where it will be covered by the helmet, but not entirely.

Constraints

Economic

Economically, we expect the hardware to put on the helmet to cost about $300-$400 to produce. Helmets themselves cost between $350-$450, depending on the brand. This price is in line with a lot of what fire fighters are currently paying for gear. However, given that it costs $300-$400 to produce a single module, we would expect it to sell for at least double to make a small profit. This brings our module to anywhere between $700 and $900. If we decide to mount most of this on a necklace, then we can expect the cost to dramatically decrease by the price of the helmet. So, we would be looking at a cost closer to $500 in that case.

Environmental

Environmentally, we expect our device to be on par with the environmental harm of most electrical devices. Obviously, we do not want these devices disposed of (after their three-year lifetime) improperly as to be detrimental to the environment. We will encourage the recycling of these parts and hope that some of them can be reused by us to continue to make new modules. Like most electronics, disposing of them improperly can result in toxic fumes. We would try to recycle what we can and dispose of the rest through a certified e-waste organization. Properly disposing of the battery would be essential too.

Social

We intend to make this device user friendly and well as law abiding. However, we do not want to create this for public use. Given the excessive cost we expect it to only be available to companies that may need them in bulk quantities. For this project, the goal is for it to aid fire fighters; however, in the future we hope to expand this idea so that it can find its way into the oil and gas industry and law enforcement as well with proper sensors outfitted in those respective jobs.

Political

The only thing that may come close is the environmental hazard this device could potentially be when not being disposed of properly. However, given that it is not for public use and our efforts to recycle and properly dispose of parts, we are confident it will not cause harm to the environment.

Ethical

We see this design as being ethical in that the benefits outweigh the costs by dividends. Our goal is not only to keep our firefighters safe, but to keep them operable in harsh conditions if possible so that they can quickly and efficiently do their job, and potentially save lives. Environmentally, electronics as a whole are not exactly ethical when considering the harm they can cause to the environment, but we intend on taking every opportunity possible to recycle and properly dispose of these modules.

Health and Safety

The one health and safety constraint we hope to focus on is how operable and safe our device will be under intense heat. We want this to not be a concern and as such will make every effort to use the proper heat-proof sensors as well as create fire/heat-proof storage of this device that can still be easily placed on existing turnout gear.

Manufacturability

Given the state of this pandemic it is hard to come by parts, so we expect there to be manufacturing delays and limited numbers as of now. As access to the parts, we use in this module becomes scarce or more expensive, it can be expected for the price to increase rapidly. We are not directly affiliated with any of the companies that produce these parts and cannot say for sure whether this should be something to worry about. However, there are plans to try to create these parts ourselves if possible. However, this too would increase the cost of our design.

Sustainability

We have already discussed all of this in all of the previous constraints. We intend for it to be sustainable assuming we can source the parts for the design. We do not see our device having any issues in terms of legality, socially, or politically as long as we are able to make it safe for the user.

Technical Details

Our project will follow this simple system dynamics chart:

Since we want this project to be able to support the intense heat of the environment the firefighter will be in, we will be using low-power consumption sensors. Furthermore, we will be using sensors that will support elevated temperature environments and still be able to output accurate data. Most of the sensors we are using only need 3.3 volts to run efficiently. Also, most of the sensors have Arduino libraries already developed and tested.

For the networking section of this project, we are still deciding on two different options: to use MQTT communication protocol with the ESP32 and publish messages to the Node-RED Dashboard or to build an asynchronous web server using the libraries available in the ESP32. If we use the Node-RED, it will work like this:

To begin, the ESP32 will connect to the Wi-Fi, the IEEE 802.11ac standard will be used. Then the ESP32 will publish the sensor readings for each component that we will be using. The sensor’s value will be read in real time and be published on the Node-RED dashboard. The only problem with this is that we will need a Raspberry Pi to use Node-RED. Furthermore, we will need to explore how Node-RED works. The advantage of using Node-RED is that it can also be accessed from anywhere. To clarify, Node-RED can be installed in Digital Ocean, a cloud service. Having Node-RED on the Digital Ocean would allow the user to access and monitor the dashboard from a computer or smart phone from anywhere in the world. However, Digital Ocean is not a free service. The other option is building an asynchronous web server. With the asynchronous web server, we will be using the available library in the ESP32: ESPAsyncWebServer. With this library, and other libraries, we will be able to display all of our sensor values on a chart. The asynchronous web server will work this way:

The data will contain the index.html file and the Arduino sketch. Essentially, the index.html file will be a chart that will read the values of the sensor from the Arduino sketch. The advantage of using this option is that we can modify the charts to how we want it. Furthermore, we can add more charts to display the different sensor values.

The most critical feature of our project will be getting the location of the firefighter. To determine the indoor location, we will be using Ultra Wideband Bluetooth technology (UWB), which has been proven to be better than Wi-Fi and Bluetooth because UWB is a system used to determine the time of flight of the transmission at various frequencies. The distance is calculated by using this equation: 📷”. Researching more about how UWB works, we learned that it works in two methods: Single-sided two-way ranging and double-sided two-way ranging. The first method, single-sided two-way ranging is the most basic way of measuring and is not that popular. Therefore, we will be using the second method because its more efficient and more reliable. Its more reliable because intensive calculations are made for the time of flight. “The time of flight is calculated using this equation: 📷”. Now that we have decided on using UWB, we need to find a device that has this feature. We found out about Decawave DWM 1000. This device works in two methods: as a tag or as an anchor. “The tag is defined as the subject that will be moving around and the anchor is defined as the sensor that will be positioned at a known location. The more anchors there are, the more accurate the distance will be [3]”. Furthermore, considering how advanced technology is today, we discovered that UWB technology is available on new phone models. The iPhone 11 (and above) and new Android phones have UWB technology that could work with the DWM1000 sensor. After researching more about the DWM1000 sensor, we discovered that it works with the android phone and not with the iPhone. This means that we could use the phones as tags. Currently, we are still working on understanding how the DWM1000 sensor works and how we can use it efficiently.

We found using the DWM1000 on its own would be too costly, as we would need many more parts to get a working GPS location system. So, luckily, we found an ESP32 Development board with the DWM1000 already installed on it: ESP32 UWB Module. This will save us time, money, and space so that we can implement this quicker. Because of the setbacks with the DWM1000, we decided to test and connect all our other sensors since we knew we could do it quickly. We were able to get a working gyroscope (MPU6050), gas sensor (MICS6814), oxygen sensor, and barometric pressure sensor (BMP280). With the gyroscope we will be able to tell if a firefighter is conscious and moving around still, with the barometric pressure sensor we will be able to estimate the height that the person is up in the building, and with our gas sensors we will be able to gauge what is a safe level of toxic gas for the firefighters and what is not. Also, what we plan to do is to display an accurate location of an individual and display the data to a server. Before we begin, we will need to “setup the ESP32 with the proper libraries and install ESP32 add-ons in Arduino IDE [4].”

Once “we learned more of how Node-RED worked and how easy it is to build applications [5]”, we decided to choose the option of using an MQTT broker with Node-RED. However, instead of running it locally on a raspberry pi, we will be running it on Digital Ocean. We chose this option because “we discovered that MQTT is popular for IoT projects and is efficient in collecting data from sensors and publishing it on a server [6]”. Once we made a Digital Ocean account, we proceeded to installing an MQTT broker and Node-RED. Once we had both Node-RED and the MQTT broker installed, we needed to configure Digital Ocean. To clarify, we needed to change and add some firewall rules to our server, so we could connect to our device. Using NIST Framework, we administered credentials to use for out MQTT broker and NodeRED service. Since the MQTT broker uses port 1883 and Node-RED uses port 1880, we need to allow inbound TCP rules for Node-RED and MQTT. Essentially, we are using the principle of least functionality. This principle is incorporated by configuring systems to provide only essential capabilities (PR.PT-3: NIST 800-53). We also needed to add UDP rules since the DWM1000 works best with UDP. Furthermore, using NIST framework, to manage remote access to our server, we added SSH keys (PR.AC-3: NIST 800-53).

We have Node-RED and our MQTT broker running on Digital Ocean, which means that our server and dashboard can be accessed from anywhere that has an internet connection. Since our dashboard can be accessed from unknown users, we made Node-RED require a username and password. Furthermore, we also configured our MQTT broker to require a username and password. Using NIST Framework, we administered credentials to use for out MQTT broker and NodeRED service (PR.AC-1: NIST 800-53). After adding more security to our server, we made a dashboard that would display the sensors’ values and the distance from the anchors. In our first tab called “Home” we are displaying the altitude, temperature, and pressure values from the barometric sensor given to us. Below the barometric sensor, we are displaying the current oxygen level in the environment. Next to these sensors, we are displaying values from the gyroscope/accelerometer (MPU6050). On the top we have the accelerometer section, and, on the bottom, we have the gyroscope section.

On the next tab, “Gas Levels and Distance, ” we are displaying the current gas levels in the environment and the distance in meters the tag is from the anchors.

For the distance, we attempted to create a scatter graph that would map out the area like the image below. However, we were unable to create a real-time graph in node red because we needed to learn how to use the library, D3.js. We needed more time to learn JavaScript and CSS.

Instead of using a graph on NodeRED, we decided to use Unity3D. Unity3D is a game application that also works well with 3D projects. Using the documentation available of the ESP32 with the DWM1000, we built a Unity application that would take the distance from two anchors and visually display the person and their location. The Unity3D application will work similarly to the python turtle example given by the documentation of the ESP32 device.

The Unity3D application will show the two anchors and the tag. Furthermore, the Unity3D application will update the location in real-time. Since we want to make this as fast as possible, we will be using UDP and not TCP. Since Unity3D is used for building games, this will work great with UDP. Furthermore, a library in Arduino IDE already exists that uses UDP to send data. To get the Unity3D application to work we had to do some research and combine two methods. The two methods combined are from two different online videos. One with two anchors [8] and the other with three anchors [9]. We took the good sections of each and combined them.

Essentially, the indoor location works as it is shown below. The tag will get its position based on the two anchors. Then the tag will connect to the computer through Wi-Fi and then the computer will graphically display it.

We are testing the indoor location using a triangle shape: two anchors placed at the same horizontal height and the tag is placed some distance between the two anchors. The anchors must be placed at the same height or else the tag cannot receive a proper distance. We will name the anchors A and B, and the tag will be C. To get the distance from the tag and anchors we will be using the law of cosine: 📷. Then to find the angle of A we rearrange the equation: 📷. Then we use the Pythagorean identity to give me the sine of angle A: 📷. Once we have are calculations, we need to send it to our computer. However, before we do, we need to decide on what mode to use. To clarify, the ESP32 UWB module has many modes of operations pre-configured: LONGDATA_RANGE_LOWPOWER, SHORTDATA_FAST_LOWPOWER, LONGDATA_FAST_LOWPOWER, SHORTDATA_FAST_ACCURACY, LONGDATA_FAST_ACCURACY, LONGDATA_RANGE_ACCURACY. We decided to use LONGDATA_RANGE_LOWPOWER. Once we have configured the Arduino sketch, we need to look up our local IP address and add it to the sketch, so the ESP32 knows where to send the location data. Before moving on to the anchors, we need to make sure we set the ESP32 as a tag. Once we do we upload the code. Next, we need to set up the anchors with the same mode of operation. Then we need to give the anchors a mac address so the Unity application will know from which device it's receiving data. We can set one anchor as BB:AA:5B:D5:A9:9A:E2:9A and the other anchor as DD:CC:5B:D5:A9:9A:E2:9B. We upload the sketch to the anchors and then we turn them on and move the tag around. The user then can see that the Unity3D application will then be updating the position of the tag. The tag will be slightly inaccurate; therefore, we need to calibrate the device. To calibrate the ESP32 UWB module, verify that you have the modified version of the DW1000 library. Once verified, make sure to download the file from Makerfabs called ESP32_UWB_setup_tag.ino to the tag. Then, place the tag and anchor at a fixed distance. The fixed distance can be between 2 and 8 meters. Better results are seen if the distance is 8 meters. Next, download the ESP32_anchor_autocalibrate.ino and set the anchor distance from the tag. Upload this code to the anchor and open the serial monitor. Record the Adelay and change it to the one showing in the serial monitor. There should be a visible change to the accuracy of the UWB module.

The UWB module wasn’t the only sensor we need to calibrate. Fortunately, the other sensors were not that challenging to calibrate. First, the oxygen sensor was the easiest to calibrate. The oxygen already has a calibration button, so we just pressed the button for two seconds and it was calibrated. Next, the gyroscope (MPU6050). To calibrate the MPU6050, simply have the MPU6050 Adafruit Sensor Lab downloaded and upload the “zero rate simplecal” to the device. This process should take about 1-2 minutes and its done. Next, the barometric pressure sensor (BMP280). To calibrate this sensor, simply look up the current pressure in hectopascal and set it in the code. Lastly, the gas sensor (MICS 6814). Simply download the library and upload the calibrate code.

Cost Analysis

Some of the components that we used for our project were already in our possession and some we borrowed from the engineering supplies. We provided a table below that breaks down the cost of the project.

Design Alternatives

During this project, we have considered many design alternatives. Our first design was to simply use the Arduino with a Wi-Fi module, possibly the Espressif ESP8266. Since our first design required more components to purchase, we thought that it would be best to use the Arduino UNO WIFI REV2, which is an Arduino UNO board with Wi-Fi. However, when we visited the website to purchase the Arduino with wi-fi, it was out of stock. Furthermore, we needed more pins than the Arduino UNO had. Therefore, we decided on another design alternative. We considered using the Raspberry Pi with Arduino UNO. In this design, the Raspberry Pi would handle all the networking capabilities and the Arduino would handle the rest of the sensors. Furthermore, using this design was more suitable for us since we already had the Raspberry Pi and the Arduino board, and we are familiar with how to use them. However, since we want this project to be as compact as possible, instead of using the Raspberry Pi, we considered using the Raspberry Pi Pico, but the Raspberry Pi Pico has no Wi-Fi capability. If we use the Raspberry Pi Pico, we needed to add a Wi-Fi module, which would make our design larger. Our last design alternative was to use the Arduino Lilypad with a Wi-Fi module added, Xbee. However, like most of the sensors, the Arduino Lilypad with Wi-Fi capability was out of stock. A last design alternative that we are likely going to use is the ESP32 with the UWB sensor. In this design, the ESP32 will handle the networking and the sensors. Furthermore, since it is already integrated with the UWB1000, it will also handle the indoor localization. Additionally, we realized that because the person using this device will be in a burning building at some point, the barometric pressure sensor will be inaccurate due to various levels of air pressure when fire and other gases are involved. Because of this, we will either need to find an alternative sensor for our design that does not work based on pressure or we will need to look for one specifically made for handling heat. Lastly, we thought of making our design more like equipment and not an add-on to the helmet.

Future Expansion of Project

Since we had a limited budget and most of the sensors were out of stock, this project can be expanded further. If we construct our project small enough, we can enclose our project in a flexible heat resistant fabric or enclose the sensors in some thermal pads. Also, to prevent overheating, we can add small semiconductor refrigeration tablets or some kind of cooling system available. In addition, we can replace some of the sensors with more accurate sensors. For instance, the gyroscope can be replaced with the 9DoF Absolute Orientation sensor, which outputs acceleration, angular velocity, linear acceleration, gravity, and temperature. Also, some of the gas sensors can be replaced and upgraded with more accurate sensors too. For instance, for this project we are using the bmp280 which has been replaced by a more reliable sensor, bme680. To expand more on this project, we can make a real-time database with Firebase to record the sensor values and log all the values the sensors have read. Another idea is to create a web page that displays sensor readings. This way we can view sensor readings from anywhere in the world. This can be done with the ESP32, MySQL, and PHP. Furthermore, in addition to the unity application, there can be a NodeRED chart, like the one demonstrated earlier, that maps the area. On the security side, an IDS like Suricata can be used on the Digital Ocean server.

References

[1] R. Santos, "ESP32 MQTT – Publish and Subscribe with Arduino IDE, " Random Nerd Tutorials, 25 March 2020. [Online]. Available: https://randomnerdtutorials.com/esp32-mqtt-publish-subscribe-arduino-ide/. [Accessed Janurary 2022].

[2] Makerfabs, "ESP32 UWB Indoor Positioning Test, " Makerfabs, 22 December 2021. [Online]. Available: https://www.makerfabs.cc/article/esp32-uwb-indoor-positioning-test.html. [Accessed December 2021].

[3] Makerfabs, "ESP32 UWB, " Makerfabs shop, 9 Feburary 2022. [Online]. Available: https://www.makerfabs.com/wiki/index.php?title=ESP32_UWB. [Accessed Feburary 2022].

[4] R. Santos, "Installing the ESP32 Board in Arduino IDE (Windows, Mac OS X, Linux), " Random Nerd Tutorials, 17 December 2016. [Online]. Available: https://randomnerdtutorials.com/installing-the-esp32-board-in-arduino-ide-windows-instructions/. [Accessed November 2021].

[5] S. Cope, "Steve’s Node-Red Guide, " Feburary 2021. [Online]. Available: https://stevesnoderedguide.com/. [Accessed November 2022].

[6] R. Mitchell, "HTTP vs MQTT - Which Communication Protocol Should You Use in Your IoT Application?, " Electromaker, 12 May 2020. [Online]. Available: https://www.electromaker.io/blog/article/http-vs-mqtt. [Accessed November 2021].

[7] Node-RED, "Mapping 2d at Dashboard, " Node-RED Discussion Board, 18 August 2018. [Online]. Available: https://discourse.nodered.org/t/mapping-2d-at-dashboard/2661. [Accessed Jan 2022].

[8] E. N, "[ESP32 + UWB + IMU | Indoor Position & Rotation + Unity Visualization], " Youtube, 27 March 2022. [Online]. Available: https://www.youtube.com/watch?v=fPuxcjHsfpc&ab_channel=ThatProject. [Accessed April 2022].

[9] Alistair, "Ultra Wideband Realtime Location System using ESP32 and Unity, " Youtube, 27 Janurary 2022. [Online]. Available: https://www.youtube.com/watch?v=-GNkobAxao0&ab_channel=PlayfulTechnology. [Accessed Feburary 2022].

[10] Makerfabs, "ESP32 UWB Antenna Delay Calibrating, " Makerfabs, 24 Feburary 2022. [Online]. Available: https://www.makerfabs.cc/article/esp32-uwb-antenna-delay-calibrating.html. [Accessed March 2022].