Posted on

Neha’s Status Report for Feb. 25, 2023

This week we spent a lot of time preparing for our design review presentation. We finalized a lot of details that we had spent the majority of last week researching. Now that the designs have been primarily finalized, we have placed orders for the Zigbee shields, ESP32-C3 development boards, displays, and batteries. We decided on the approach to just purchase 2 Xbee hats in order to show that in the event of a wifi outage, we have a plan for how we can rely on a source other than the local network which we can explain how to scale up. While presentations lasted two days and we didn’t have that class time, we all met outside of class to work on the hardware we already had, research new parts that had gone out of stock since we requested them, and send out new orders. 

This past week I started to plan out what should be included in the design report based on the provided guidelines. I went through a lot of different examples of reports from previous years and figured out what is most relevant and necessary to include regarding our specific project. For example, from the design presentation we learned that because we essentially have two MVPs: one for the node with the LEDs and another for the node with the display. With this information, we need to ensure that our design report goes into depth for the components that make up these different kinds of nodes. Furthermore, I think a good portion of our report is going to be dedicated to our design choices and how we got to our final design. This is because of all of the research and considerations last week that heavily influenced the design decisions we made for our presentation. With these in mind, I have a layout that I think makes the most sense to follow for our report. I believe I am on track with regards to our schedule and the next pressing item would be figuring out how to output to the display. While the displays have not come in yet that would be contingent on their arrival which I will touch on for my deliverables.

Regarding my deliverables for next week, on Friday, the ESP32s came in as well as the batteries and early next week we plan to see if we can interface with them. From the previous week we were able to test our temperature sensors with an Arduino, but now that we have our ESP32s it will be important to be able to interface with them and ensure that we know how to read and write data from our sensor readings. I anticipate there to be a learning curve but I am hoping that because of our extensive research into picking these boards we were able to prioritize the interfacing capability so that there would be documentation that we could follow. Ideally, our displays would arrive sometime before spring break and we can work on being able to display information that we program on the board. I anticipate this learning curve to be big as well despite choosing displays that are compatible with ESP32 so we would want to ensure that we plan accordingly while still being on track to complete our project. Regarding the nodes with the LEDs, that would depend on the output from our pathfinding algorithm as well but now that we have our ESP32s, we should be able to test that we are able to drive certain LEDs and not others instead of just testing with the Arduino like we had done last week. With these action items in mind, we will also be working on completing our design review report as the deadline is by the end of the week.

Posted on

Aidan’s Status Report for Feb. 25, 2023

At the beginning of the week, most of my time was spent putting together our design review presentation with Neha and Jason. As we were putting our slides together, we were forced to make finalizing decisions for our project. This process was very helpful in determining exactly what our final product was going to look like. After we had finished our presentation, our group decided that I would present it, so I spent some time rehearsing it, ensuring that I would be able to give the presentation without relying on the information on our slides. We also were not able to use our class time the same way that we were able to in weeks that don’t have presentations, but we met outside of class when we had topics that we needed to discuss.

 

After this, I began writing up some sections of our design report. I began by writing a rough draft of the abstract and the introduction. For the introduction, I outlined the problem that we are hoping to solve and then proposed our solution to the reader. I focused on excluding technical details, as these seem better suited for further on in the paper. Additionally, I spent some time figuring out how we want to format our use-case requirements. My initial thought was to include the table from our proposal, however after much trial and error, I believe that attempting to create a readable table that is located in the correct spot in Latex may not be the best solution. Unless we can find a way to make this more reader-friendly, I think I may revert to writing our requirements in paragraph form.

 

Additionally, I spent some time converting my distributed pathfinding software to a version that would be compatible with our ESP32 microcontrollers. Initially, I was using python to quickly develop a prototype, however after some research, we could not find if micropython was supported on ESP32 C-3. Therefore, I decided to use C++ as we know that our microcontrollers are compatible with the Arduino IDE. Before beginning the conversion, I had to do some research on the aspects of C++ that I was hoping to use, however after some refreshing, I was able to begin coding. I was able to complete the code for the structure of our pathfinding software that will run on each node. In essence, each node will check and see if its neighbor is an exit, and if it is, then it will plan its path to the exit. After this initial check, each node will constantly be checking for other paths sent by other nodes. From these sent paths, each node is able to determine the shortest safe path to the exit. Currently, I have placeholder functions for the functions requiring communication(send() and read()), as I will need to look into the protocols and libraries used for Wifi and Zigbee communication. Additionally, the code only supports one exit node at the moment and I am hoping to test this before incorporating multiple exit functionality. Even with these placeholders, the code does compile and can be found here:

https://github.com/jtledon/18-500_Capstone_FireEscape/blob/path_finding/Pathfinding/singleNode.cpp

At the moment, I am on schedule for my tasks. The main technical task that I was hoping to accomplish for this week was to write a C++ version of my pathfinding code. While I did complete this on time, it has made me realize an additional step that I will need to add to my schedule: integrating the pathfinding code with the communication code. One of our tasks for next week is getting our nodes communicating with each other, so after this, I will be able to start writing our necessary write() and read() functions. It does not make sense to run this pathfinding algorithm on just one node because the computation is distributed across all nodes. This means that we will not be testing the functionality  and accuracy of our C++ implementation until we have our communication working. Next week, my top priority is finishing our design report. Additionally, I will be focusing on getting our communication to work, as this is a blocking point to some of our further development. Additionally, I am hoping to get something to display on our sensors next week and figure out how to output to these displays, however, this is only if the displays arrive during this coming week. Lastly, we will have to push back our testing of the smoke sensors as we are still waiting on these to arrive.

Posted on

Team B8 – FireEscape’s Status Report for Feb. 18, 2023

One of the significant risks that could jeopardize our project would be finalizing microcontrollers that fit all of our needs. For example, a lot of our time this week was spent picking parts that met different concerns like cost, reliability, compatibility with Zigbee and displays, etc. Unfortunately some of the boards we thought were most ideal haven’t even been introduced for public use yet. Our project would like to take into consideration the possibility of the wifi going out, which is why we knew we wanted to take advantage of a distributed, node based network like ZigBee. However, because some of the ZigBee cards that we have found can be pretty expensive and we have a lot of nodes, we wanted to explore alternatives. In order to make progress we decided to proceed with ESP32s and use a local network. However, because we want to take into account that the network needs to stay up, even if the WiFi goes out, we plan to order a couple Zigbee shields to show that we can make this change if necessary and explain how it would scale up. Additionally, we will explain how our system had to use only a couple Zigbee shields due to availability problems and long lead times, but that if this project was put into production, we would hopefully be able to order these parts and deal with the long lead times. This would give all of our nodes Zigbee capability, while staying under budget. This is the largest change that our design underwent this week.

For pathfinding, we are testing two pathfinding algorithms against each other. The first is a Dijkstra’s search that will work well if each node has access to the status of every other node. In the case that each node is connected to Wifi, this is a realistic scenario. Our second algorithm is a Dijkstra-Schlater search: this is a distributed Dijkstra’s search in which each node infers the shortest path from itself to the exit by receiving the shortest path from its neighbors to the exit. 

Both have pros and cons: Dijkstra-Schlater would probably scale better, but vanilla Dijkstras would probably have better latency. We are planning to implement them both and do real-world testing to figure out what we want to use on our final design. We also plan to test A*, which is nearly identical to Dijkstras, but with an added Heuristic function. 

Jason has pushed back his schedule by a few days to take into account some of the issues he had finalizing what hash map and priority queue implementation he wanted to use. Due to some of the slack time that was built into his deadlines, this shouldn’t impact the rest of the timeline or integration. 

Our project recently has relied on 18-349, 15-210, 18-220 for our knowledge of pathfinding using Djikstra’s algorithm. Beyond these courses, we relied on a lot of external research on datasheets and tutorials of the different displays, sensors, microcontrollers, etc. We also spent a lot of research on distributed nodes and how we can run distributed pathfinding algorithms for each node so we can ensure that if a node went out we can still have an optimal path passed to a neighboring node.

One of the engineering principles that we kept in mind while we were designing our project is Usability. We wanted to make sure that our product was easy to use. When people are escaping from a burning building, the do not want to be spending much time trying to figure out our system. One of the ways that we used this for our design is that we prioritized display size. We wanted to make sure that the displays would be big enough for our user to read quickly and effectively. Many of the displays we saw had around a 1 inch diagonal, but with further research we found one that is over 3 inches. Another engineering principle that we used is redundancy. In distributed systems, it is important that if one node goes down, the others will be able to continue their tasks. For our project, we have ensured that our system will be able to survive a node going offline. This is especially important for us, as our nodes may be subjected to extreme heat. Additionally, we are providing redundancy in our sensor by using both smoke and temperature sensors.

Posted on

Aidan’s Status Report for Feb. 18, 2023

At the beginning of this week, I conducted research on batteries that we can use as backups for our nodes. This involved researching how much power an ESP32 consumes (~40mA on idle, ~120 on active mode) and performing calculations to ensure that our nodes can run on idle mode for 24 hours and 5 minutes on active mode. Through this math, I determined that we would need at least 500mA, but we also decided that depending on the peripherals we are planning to use (Zigbee card and display), we may need more and we were able to find a pack of 10 1000mAh batteries that was within our budget, so we decided to purchase these. Additionally, I researched the circuit that I am planning on using as a backup circuit and this is what I came across:

This is from: https://www.allaboutcircuits.com/projects/battery-backup-power-supplies/

The circuit allows the battery to be charged while it is not being used, but once the power goes out, the battery will be able to power our microprocessor.

This week I also spent a lot of time with my group deciding which items we were going to order for creating our nodes. We were able to find displays that were within our budget and had the functionality and size that we wanted. We also were looking into ESP32 boards that had built in Zigbee functionality that Jason was able to find, but these recently sold out, so we are planning to buy 2 Zigbee boards that we will use to demonstrate our backup network. We our Zigbee network. will plan on setting up our system using Wifi or Bluetooth and then in the case that this system goes out in a fire, we will show that our system can successfully switch to 

Additionally, this week we received our temperature sensors. Neha, Jason and I worked to set up a circuit on our breadboard. After downloading the Arduino packages, we were able to measure the temperature and light up an LED once a threshold was reached. We used a lighter to test the increase in our temperature sensor. 

On my own, I have spent a lot of time getting our distributed path finding algorithm working. This algorithm is described in: https://www.cs.utexas.edu/users/misra/scannedPdf.dir/DistrShortestPath.pdf

, but it essentially involves a bottom up algorithm that builds paths from the nodes closest to the exit, propagating these paths up through the graph. Using the framework that I was able to get working on this week, I have created a simulation that will take in a number of nodes, a list of edges, and a goal node. Then, a separate thread is created for each node and they begin running the pathfinding algorithm. The nodes that are neighbors to the goal node define that they have an edge to the goal and they send this information to their neighbors. The neighbors receive this message, and if it contains a shorter path than their current solution, it is updated to have this shorter path as its solution and it sends this solution to its neighbors. Currently, this code assumes edge lengths of 1, but by adding an extra field to the sent messages, I will be able to specify different lengths for each edge. This code can be found here:

https://github.com/jtledon/18-500_Capstone_FireEscape/blob/path_finding/Pathfinding/functions.py

https://github.com/jtledon/18-500_Capstone_FireEscape/blob/path_finding/Pathfinding/distPathfinding.py

 

One of the courses that I have used a lot this week is 15-440. In order to make sure our distributed simulation would work correctly when transferred to our physical nodes, I had to take into account the time it can take for messages to be sent, as well as how to receive and handle incoming messages without blocking and freezing the operation of the pathfinding algorithm. I also used what I learned about threads from 15-213 to better understand the simulation that we are using and the simulated nodes running on different threads. Additionally, My time spent in 15-281 and 15-210 helped prepare me to write the pathfinding algorithm as this is covered in both of these classes. For the breadboarding that we were doing, I used what I learned in 18-100 and 18-220. To program our arduino and select valid resistors and circuit elements I had to use information from designing circuits in 18-220. Additionally, when I was performing calculations to determine what battery we needed to power our boards, I had to rely on the knowledge I have about current, voltage, and resistance that I learned in 18-100.

Currently I believe my tasks are on schedule. One of the tasks I was planning to have done this week is breadboarding. We have completed breadboarding for the sensors we have available. The one change to this schedule that we will have to make is that we will add to our breadboarding as our sensors and microprocessors arrive. We will continue to add to our circuit and once the boards come, we will switch from breadboarding with an arduino to breadboarding with our new microprocessors. My distributed path finding algorithm is now running on a laptop on my distributed simulation which was my goal for this week, and I am planning on converting it to code that can run on a microprocessor next week. I am also planning on running further tests on my current code to iron out any bugs that may be present. However, one setback is that we will need to wait until we have our microprocessors and communication setup to test the distributed pathfinding. This coming week, in addition to converting my distributed pathfinding code, I plan on working with Jason to get the LED’s to light up on our Arduino (or other microprocessor if they arrive by then) based on the solution of our pathfinding algorithms. In addition, I plan on working to add our smoke sensors to our breadboard if they come early, although they estimated arrival is March 1st.

Posted on

Jason’s Status Report for Feb. 18, 2023

This week I spent more time than I had intended researching ESP32’s, their different types, distributors, wireless capabilities, and considering alternatives to what might happen if we can’t get the boards we are interested in. When Aidan, Neha, and I were looking into what boards to order, I realized I didn’t know the difference between an ESP32 or ESP8266, or how an ESP32-S2 differed from an ESP32-C6 differed from an ESP32-H2. These links – a b – ended up being the most helpful in figuring out the differences between them. Ideally, the team would be able to get an ESP32-H2, because that was supposed to be the first board from ESPRESSIF (the maker of ESP32) that natively supported the ZigBee standard. The issue with the H2 is that it isn’t released to the public for general purchase yet. That being said, in my research, I realized that the ESP32-C6 surprised everyone by including ZigBee as well, and therefore was the board I let the team know I thought we should get. The issue with this board, however, has been finding a supplier with a stable inventory.

As of writing this, I just checked and saw that the ESP32-C6 Dev boards that we submitted a purchase order for has just sold out, and I will be working tomorrow on finding a replacement.

One of the other quirks that come with using some of the ESP32 boards is that they don’t all support the Arduino IDE; instead, some use the ESP-IDF development environment. There are a couple of ways to interface with it, and luckily its documentation seems to be quite thorough with a Github that provides tools for getting started developing projects. 

As for the pathfinding, I am slightly behind schedule for the C implementation of Dijkstras. I spent a lot of time researching the differences between the different hash maps that are available in C. I was primarily looking at search.h, uthash, and GLib’s GHashTable. I spent a lot of time trying to figure out how to get GLib installed because it had the most functionality, helper functions, best documentation, and generally seemed to be the most performant. That being said, after a couple of hours trying to configure meson, ninja, and my general environment, and still being unable to get it uninstalled, I decided to switch to using UTHash. UTHash exists in a single header file that is available on GitHub, is still relatively performant, and is very easy to use. I think the ease of development is worth the possible performance loss. Because of my struggles with getting a hash map set up – needed for creating the dictionary representation of the graph, which maps a node to its neighbors – I was put slightly behind schedule. 

I built in a couple of days into my schedule (2/20 – 2/24) for possible debugging time, so I intend to push back my Arduino pathfinding to light up LEDs back by a few days to give myself some additional time to finalize Dijkstra’s implementation in C.

I was also talking with Aidan about 2 slightly different approaches of pathfinding. Approach 1 was to give all nodes information about the entire graph, and have them complete pathfinding out entirely on their own, using temp data from other nodes. The other approach is to only give each node only information about its neighbor node, and find the optimal path based strictly on the information returned to the node by its neighbors. We think this approach might scale well but could face some latency issues. We decided the only reasonable way to test it would be to write both solutions and time which one runs faster in a real-world application, as we don’t have a good way to simulate the added latency of sending increasing amounts of data.

I also refactored my Dijkstra’s version of the code in python so I have a better reference to use when finalizing the C version. I added a bit of bash scripting for ease of testing the code as well: 

(these weights are slightly different than the actual ones I used in the code)

This upcoming week, I want to finalize my C implementation of Dijkstras, time it relative to my python implementation to check the performance difference and run valgrind on it, to make sure we don’t have memory leaks, seeing as these need to run for a long period of time without maintenance. When that is finished, I plan to set up the infrastructure to light up LED’s based on a hardcoded starting node, to indicate where to go next. Based on the way I have my code set up now, it would require very minimal changes to the structs that I am using. 

I think the classes that covered what I worked on this week fit into two categories: the first category is pathfinding, which is mostly just 15-210, which is a CS class, but it covered Dijkstras in depth. The second category is writing C code, which is 18-213, 18-344, and 18-335 where I learned how to organize C projects to make them manageable, use header files properly, Makefiles, etc. I think the final class that helped would be WebApps, because that class had such an open-ended project, I had to do a lot of research, which I had to do a lot this week when trying to decide what ESP32’s to buy. 

Posted on

Neha’s Status Report for Feb. 18, 2023

This week I spent a lot of time meeting with Kaashvi and the rest of our team to try and finalize the hardware that we want to order. This is because originally we were all under the assumption that the nodes would be made up of arduinos. After looking at the inventory, we realized that if we wanted to use arduinos, it would get really expensive really quickly. So, we decided to branch out to using other microcontrollers and we decided that NodeMCU ESP32 was our best option. Once we figured out this part, we started to move on towards finding the exact Zigbee shields that we needed after learning that these are actually quite expensive as well. Then we started to look for development boards that had Zigbee capabilities included and realized that either they were not released to the public just yet or they came from unreliable sources. As of now, we think our best option would be to use regular NodeMCU ESP32 development boards and buy a couple Zigbee shields just to prove that in the event that the wifi connection went out, we have a working solution for how to get around it when it comes to scaling up for our demo. We put in an order and hope to get them reviewed and sent out as soon as possible. Once we have the microcontrollers we also finalized decisions on the displays which we sent out as well. We wanted to ensure the displays we picked were big enough for users to read while being in a hurry to get out of the building but also compatible with the ESP32s and shipping from a reliable source. Trying to get a balance of these three components was a bit tricky but we think we found a good selection of displays and sent those out to be ordered as well. Further, we are still waiting on our smoke sensors as they were shipped from ebay which will take until March 1, but we were thinking of finding smoke sensors from a more reliable distributor so we can get and test them as soon as possible. Finally, our temperature sensors came in this week and on Friday we were able to use an arduino just to test its capabilities and thresholds using a lighter. We kept note of the delay of recognizing the temperature and how long it stays at a certain threshold before cooling down. We also added an LED to detect certain ranges and turn on/off at different cutoffs. All of these considerations will be present in our design review presentation.

According to the Gantt chart, my progress seems to be on track. It has been a little frustrating not getting the parts completely ordered but I’m glad we were at least able to test the temperature sensor as it aligns with our schedule. Ideally we could’ve tested smoke sensors as well and instead of using an arduino we could use the ESP32s but we only made that decision later in the week so we tried to keep up with our schedule in this way. We were also able to scope the battery requirements and send out a request for the batteries we want to use for each node which is on track with what we had planned. But those orders we placed will likely only go out next week. All in all, I am pretty much on track with what we had proposed but we anticipated a quicker turnaround time for all of the parts that make up the structure of our nodes.

In the coming week, I want to be able to find a good smoke sensor from a reliable source and start testing that immediately. I also want to figure out how we need to wire the battery to the rest of the node so we can be able to recharge it in the event of a power outage and allow this to be the source of power when necessary. Once we figure out how these circuits are configured and the layout of the ESP32s, we can utilize our Eagle research and plan how we want to design and fabricate our PCBs. We also know that our design report is coming up so we want to make sure that we have a finalized plan and can explain any design choices that we make and show the progress we have made towards those plans.

This week, the ECE courses I have been working on the most have been circuits as well as some software systems with the arduino/microcontroller programming (specific courses would be 18-220, 18-349). These courses aided in support for diodes to recharge batteries, arduinos to read data from sensors and power LED, and general decision making and design planning considerations regarding the research we have been involved with this week. Outside of these courses, we spent a lot of time researching online to learn about what is going to work best with our design (ie what sensors/displays are compatible with certain microcontroller, what batteries fit the design requirements, etc.).

Posted on

Aidan’s Status Report for Feb. 11, 2023

At the beginning of this week, I worked with Neha and Jason to complete our proposal. The two most time consuming parts of this were creating our schedule and finalizing our requirements. To finish our requirements, we had to do a lot of research on fire codes and industry standards for fire alarm systems. However, now that we have completed these, I feel that the schedule and requirements will really help us to structure our project. Unfortunately, I tested positive for COVID this week and was unable to attend class, but Neha and Jason were able to Facetime me into class so that I could still watch the presentations.

Later this week, I began by researching PCB design software, and I decided that Eagle would be the best option for us, as Neha and I have both used it before in 18-349 and it is available to us through CMU. Additionally, I found an Eagle tutorial that I could follow to learn how to design PCBs from scratch. This involved creating a PCB with an LED, a jumper, and a resistor. Through, this I learned how to lay out the boards, download components online, and go see the process from start to finish. This was the completed schematic and board:

Additionally, I set out to create a platform where we can test our pathfinding algorithm. I wanted this platform to be able to simulate our distributed nodes, but in a simple way so that we can focus on the algorithm and not get hung up on implementation details. After some research, I found a github repository, Distributed_System_Simulator-DSS_py, that provides a framework to allow multiple python processes to talk with one another. To begin, I wrote an introductory program that involved 10 different processes that talked with one another. This will serve as a basis for once we want to have our nodes communicate with each other for our pathfinding algorithm.

After this, I began to set up a test suite for our pathfinding. I know that testing will be incredibly important as we begin to develop our software. I decided to use pytest for this and currently have created a test file containing some basic tests. As we continue to work on our algorithm, we can easily define more tests and run them by running “pytest”. This will provide an easy to read output for us as we progress. This code has been pushed to our github:

https://github.com/jtledon/18-500_Capstone_FireEscape/blob/path_finding/Pathfinding/distPathfinding.py

https://github.com/jtledon/18-500_Capstone_FireEscape/blob/path_finding/Pathfinding/functions.py

https://github.com/jtledon/18-500_Capstone_FireEscape/blob/path_finding/Pathfinding/test_pathfinding.py

Currently, my Eagle research is on target, as the hope was to have it up and running and used by now. Our Eagle research will be put on hold for now, as we will want to figure out our design through breadboarding. We will have a better idea of our schedule for breadboarding once we order our parts and see when they will arrive. Jason has path finding running on a laptop, which was our goal for this week, and I feel that the work that I have put toward testing this in a distributed simulation, will allow us to reach next week’s goal of having the path-finding running on  Arduinos on time. This will require Jason and me to combine the work that we have been doing and ensure test that the algorithm we choose is running correctly on a laptop. Then we will transfer this code to the Arduino’s.

 

Posted on

Team B8 – FireEscape’s Status Report for Feb. 11, 2023

We think that the most significant risks that could jeopardize the project will be one of the following: making sure all the hardware integrates properly, making it clear what direction for users to go after the path is generated, or complying with the battery requirements set by the US fire code.

To try and mitigate risk, we are trying to order the hardware as early as possible to give ourselves as much time as we can to familiarize ourselves with the sensors. We will be meeting tomorrow, 2/12/2023, to come together as a team and settle on the hardware, with the hope that on Monday, 2/13/2023, we can speak with Professor Mukherjee or our TA, Kaashvi Sehgal, and get their opinions prior to submitting a purchase form. As for how we will make it clear what direction to go from a node, we are doing our best to test this functionality early: we want to test it early enough that we can decide if we will need more display nodes or if a mix of display and LED nodes will be sufficient. At the moment, we have the least amount of risk mitigation for the US fire code battery requirements: the power draw will be dependent on the hardware that we order, which has still not been finalized. We, as a team, also don’t have much experience with speccing out battery requirements and have not focused on circuit design classes in our curriculum, and therefore recharging the batteries after a power outage will require a lot of research from the group, and input from the TA’s and professors. We tried to touch on this in our proposal presentation but after presenting, we realized these are not necessarily use case requirements but specs that we need to consider and finalize for our design presentation that is coming up.

We have not had any changes to our overall system/architecture design as of yet. Seeing as we are still in the general testing and research phase, and have not run into any hurdles yet, this part of our project has stayed constant. Ideally, as soon as we order and receive the hardware that makes up the nodes, we can begin breadboarding our initial design and determine and take note of what changes need to be made.

We have pushed back our expected deadline to order our hardware, however. We originally had that scheduled for February 9th, but we wanted to take time to research the sensors more, and consult faculty. Seeing as this is only being pushed back by a few days, we don’t see this impacting the rest of the timeline that we have set up. Additionally, we have started developing the path finding software. This includes both our algorithm and the platform/test suite that we will be using to test our software. We have preliminary path finding running on a laptop, which was our goal for this week and we are planning on getting this path finding up and running on Arduino’s by the end of next week, which is consistent with our schedule.

Seeing as our project is aiming to provide potentially life-saving information to occupants of a building fire, the main consideration for our project is public health and safety: we want to make building evacuation as safe and chaos-free as possible.

We are also trying to take economic concerns into consideration. While our project is mostly focusing on large-scale buildings – residential homes tend to be too small to take serious advantage of the system – we don’t want our project to be inaccessible to construction with lower budgets: ideally, it will be available to everyone. We are taking it into consideration by trying to choose low-budget parts for our node construction; Arduinos are one of the cheapest general compute modules and have a large ecosystem of compatible sensors. The sensors themselves are quite cheap, and if we design custom PCB’s we could order them in bulk for a significantly lower price than breadboards and wire.

Posted on

Jason’s Status Report for Feb. 11, 2023

At the beginning of the week, I was working with Neha and Aidan to complete our proposal slides. This involved a lot of time looking into US and Pennsylvania Fire Code, as we knew that our group’s Use-Case Requirements were going to be dictated primarily by these standards. Once we came up with all the requirements for the project, we were able to better plan out the individual steps that needed to be completed for our project, insert them into the Gantt chart, and evenly distribute the work.

As the week progressed, I started looking into the best path-finding algorithms for our use case, their runtimes, and the general pros and cons that each provides. I am currently leaning towards Dijkstras or A*, with the heuristic function of A* being the optimal path in an ideal case: A* is generally implied to be the informed version of Dijkstras, but I wanted to run some high-level tests in python and try different heuristic functions prior to coming to a final decision. In preparation for this testing, I transcribed Wean 5’s floorplan into a graph, with possible node locations on it, so that I could work with a realistic graph during my testing. 

I implemented some basic graph creation code that outputs a dictionary graph representation; this representation of a graph tends to be the most useful in graph traversal applications. I also implemented Dijkstras, and by extension, A*, but am currently working on figuring out how I want to write the heuristic function. All code is pushed to our team’s Github.

Next week, I hope to have the final decision of what path-finding algorithm we are going to use, and switch to C code after the proof of concept in python. This will be a challenge because of the restricted functionality built into C; I will likely need to implement my own hash-maps if I don’t find any suitable libraries; I have been looking into existing dictionary/hash map libraries, such as search.h, uthash.h and strmap.h which are all looking like possible candidates, but I need to research them more to know for sure. That said, despite the added difficulty,  a low-level language like C is necessary to stretch the limited computing power of Arduinos. 

I am currently on pace with the schedule I have set in the Gantt chart; by the end of this upcoming week, I should have path-finding working on the Arduino in C.

Posted on

Neha’s Status Report for Feb. 11, 2023

This week, I gave our proposal presentation after all of us put together the slides where we made it a goal to focus on exactly where our use case requirements were coming from and how to best address them. While presentations lasted two days and we didn’t have that class time, Jason and I met after class to plan out how we should progress based on our schedule. We quickly met with Kaashvi to determine when we can order our parts as we planned to do so sometime this weekend or Monday. 

In regards to my own research, I started with the sensor research as they are hardware components that make up our node structure and we need to order these parts as soon as possible so we can start reading from them and testing the nodes individually. As for smoke sensors, I was doing research based on Arduino fire detection methods and came to the conclusion that the MQ-02 smoke sensor might be a good bet as it is low cost, sensitive to flammable gas and smoke, and available for different applications. Furthermore, I was debating between DHT-22 temperature sensor (low cost digital temperature and humidity sensor that measures surrounding air but it requires careful timing to grab data) and the DS18B20 waterproof temperature sensor which have good accuracy and works within the temperature range we want while being easily available to connect to an Arduino digital input. I definitely want to get some more feedback before placing the orders and finalizing the sensors. I was also looking into flame detection sensors which could be useful too. Ideally we can go over these choices with Kaashvi and Tamal early next week before putting in the order. 

In the coming week, we would want to ensure that we order the necessary sensors and hardware that make up our nodes. Furthermore, while we wait for them to come in we can do more research on Eagle so that once we start initially breadboarding our nodes, we can seamlessly use Eagle to prep for our PCB fabrication. I also want to do some research on the battery requirements so we have a more scoped out idea of how we will be addressing them. We also know that the design presentation is coming up and we can start planning out the slides and fixing any details that need to be considered from questions that were brought up in the proposal presentation. In regards to our schedule, I am on track with respect to the research but a bit behind with respect to ordering the sensors. We plan to get out on order on Monday so we can get back on track.