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
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.