Posted on

Jason’s Status Report for Apr. 29, 2023

The beginning of this week was heavily focused on the final presentation. Aidan, Neha and I met up to verify a lot of the metrics, finalize the content that we wanted to include within the presentation, and update the diagrams to more accurately represent the current state of the project. In additional to the overall content of the presentation, I had to focus on the actual presentation, and making sure that I knew what I wanted to say on each slide; this was relatively simple seeing as I am very familiar with nearly all parts of the project, but I could have used to work on overall pacing more.

Following the final presentation, I continued to work on the scale model that we will be using for the demonstration. I had a mockup during the last status report, but I decided to add to it and include more detail, such as how we will actually be framing it. I also put more thought into the floorplan; I tried to focus on thinking about which nodes will be good ones to show as detecting fire, and how that will impact the general path routing. I also wanted to ensure that we took advantage of the 2-story nature of the design by adding rooms on the first floor as well. This was a challenge, because the first-floor was hard to see, so after some deliberation, I decided that the best course of action would be to use wood framing for the majority of the model, but then use acrylic on two of the four exterior walls so that it would be easy to see into the model. Here is the final version of the model we will be building.

At the time of writing this, most of the parts have been cut and laid out, and assembly will happen in the next day or two.

One of the other things I have been focusing on is completing the distributed pathfinding. I have been running into some trouble with making sure that each node has the full list of paths necessary to reach the exit. Currently, I am storing the NodeIDs as a linked-list as it is being generated. This then has to be reallocated into an array once a fixed size is known, and broadcasted to all neighbors, so that they can also have access to the exit path. The issue is there is a fixed packet size that is allowed to be sent using ESP-NOW, and when testing with large graphs, this is exceeded. I tried to write a fix that would send multiple packets if the packet size was exceeded, but that had bugs.

I plan on finalizing the the pathfinding tomorrow and doing my best to ensure it has the same results as the existing pathfinding which I have tested thoroughly. To do this, I will include both header files and run both versions of pathfinding and check if they ever differ. I will also be using this to test the differency in latency between the two implementations, as that was one of the key worries we had when switching over to distributed path finding.

I am slightly behind schedule at this point, as I was supposed to have distributed pathfinding done at this point, and only be working on the final documentation, poster, etc. Seeing as this is the last week, though, I will likely just extend the duration of the task, rather than updating the Gantt chart, as there isn’t any more time to shift the remaining tasks backward.

This upcoming week, I want to finalize the model and complete and verify the new pathfinding code – including metrics. I will also be working on the final hardware integration with PCB’s with Aidan and Neha, and then focusing on the remaining logistics files that I mentioned earlier.

Posted on

Team B8 – FireEscape’s Status Report for Apr. 29, 2023

Earlier in the week, our team worked together to plan our slides for the final presentation.

This included adding in some more test metrics that related back to our design and use case requirements, filming demos of subcomponents working together, and explaining what we had accomplished so far and what we still need to work on by the final demo. As a team, we will be spending the rest of the week on integration, final poster, final demo preparation/video, and the final report as well as further testing of the full pipeline as we keep integrating components.

One of the biggest risks we are facing is the delivery of our PCBs. The PCBs have been designed in a way that allows us to mount all of our circuit components, our sensors, our display, and our battery pack into a finished product, and if these PCBs do not come in time, we will need to find another way to accomplish this goal. Our current backup plan is to utilize the larger protoboards that Quinn has ordered for us as our method of printing the PCBs at Techspark led to some issues when it actually came to soldering the components on.

While our unit tests had to do with testing the pathfinding algorithms and, the testing for our other components like fire detection would result in a success if the temperature and smoke sensor hit their threshold markers which were successful. For our LEDs/Display testing, we wanted to ensure that based on commands and paths given as an output from the pathfinding, we can correctly display the directions for all of the unit tests as well as highlight the correct path on the display for all of the unit tests. For the battery circuit, we have tested at the correct voltage necessary to ensure the batteries are recharging to use for our circuit which we got to be 7V. For our communication testing, we tested to see the range in which packets were able to be successfully sent between two ESP32s. We found that there were 0 dropped packets within a 200 ft hallway. With these testing results, we haven’t had to make any major design changes to our project as a lot of our design choices came from previous preliminary testing of designs that led to our designs. Currently, our design is fixed and we are just focusing on integrating the components for the full pipeline.

In the upcoming week, we will all be busy on integration as well as the final deliverables (demo, video, report, poster). We hope to be able to use our PCBs after going through multiple designs for correctness but we want to be prepared with a backup plan. In terms of our Gantt chart, we are behind in terms of the PCBs which we have moved to this week. Other than that, tasks on the schedule for the week are aligned with the final deliverables that we will be working on as well as building our small scale demo and having our demo correspond to this at a smaller scale and doing an entire test in a regular building.

Posted on

Neha’s Status Report for Apr. 29, 2023

Earlier in the week, our team spent a lot of time going through our final presentation slides and adding some more testing metrics and quantitative design choices. We wanted to ensure that we were able to address the design and use case requirements and show how our project had progressed over time and what more we will have to accomplish. The main focus of the week was the PCB fabrication. Early in the week, we caught an issue with the PCBs that we had just sent out for fabrication. As a result, Aidan and I had to quickly redesign, finalize, and send out a new order with the updated design. We also added more trace widths that should have been thicker as well as mounting holes for the batteries. Luckily we were able to ask Quinn to quickly send out another order with our updated design and they are currently supposed to come on May 2. This would mean that we would have to immediately solder and test. However, if they still do not work as intended, we would be cutting it extremely close for our May 8 so we would have to solder our parts onto a larger protoboard. 

In order to see if our new design was working as intended, Aidan and I reattempted to print our own PCB using the Voltera. This was the first time using the machine without Quinn and it went really smoothly. We used the new 2.5mm drill bit as well which ended up matching the mounting holes on our display, battery packs, and smoke sensors perfectly. The printing process went smoothly as well. However, when we tried to test this by soldering some components to the board, we noticed that when trying to heat the pad with the soldering iron, it was removing the conductive ink. We didn’t expect this to happen especially with the fact that we baked the board in between printing iterations. We also received our original PCBs with the issues that we caught at the beginning of the week and we are trying to see if we can test the parts without the issues that were found or if that is worth spending our time. Soldering components to those boards are a lot more reliable as well. We are hoping to wait for our new boards as they come in but are anticipating the use of a bigger protoboard as well. 

Simultaneously towards the end of the week, Jason and I started planning out and building our small scale demo. We spent the first day taking a look at the rendering that Jason created and figuring out the best way to do the rooms. Originally, we went into it thinking that we would just be using plywood but after struggling with ways to connect edges together, we started to make proper frames. We cut out the 2”x2” studs as well as some of the plywood for the interior walls, and we wanted to see if we can go to the Hunt lending booth to buy two 2’x2’ clear acrylic sheets so that we can look into the rooms and be able to see the nodes of interest and how the displays are updated as a result. 

Finally, the smoke sensors came in on Tuesday and I was able to interface with them using the ESP32 and get smoke readings. The nice thing about this sensor is that I can use the potentiometer to calibrate the sensor to the presence of smoke. All I had with me was a lighter at the time, but Jason and Aidan recommended testing using incense or blowing out the candle so I will try that as well as look up smoke readings in smoke detectors as well. The datasheet for the MQ-02 smoke sensor also had a list of thresholds for different gasses so I will refer to those as well and compare to find the threshold which shouldn’t be too hard to add into the existing code once I get that value.

In the upcoming week, we have a lot to get done. Our PCBs will be our main priority when the new designs come in. We also will have to start working on a poster by May 2 so it can be printed by May 4. We will also want to complete our small scale demo as well as work on our final report which is due by the end of the week. While this is our home stretch, we will be having a busy week. We are a bit behind schedule in terms of the PCBs as we had to order new ones, but our schedule highlights the small scale demo, poster creation, youtube video, and final report as tasks for the week which is what our current plan is.

Posted on

Aidan’s Status Report for Apr. 29, 2023

At the beginning of this week, my team and I were focused on finishing our final presentation slides. Some of the information for these slides, we could draw from our last presentation, but we also wanted to focus on inserting the progress that we had made. For this, we made sure to include a video demo and photos of our current designs and working systems. 

While we were putting these slides together, I noticed an issue with our PCB design. We had our ESP32 being powered directly through the power supply instead of through the battery charging circuit. We knew that this would cause problems, so Neha and I began figuring out a solution for this problem. On monday, I reworked our PCB design to fix this issue, as well as standardize all traces to be .3mm in width. After some final touches, we uploaded the design to JLCPCB and Quinn was able to place the order for us on Tuesday morning. This order was originally supposed to arrive on May 4th, which was a slight issue because the Techspark expo is on May 4th. This would mean that we would not be able to demonstrate our fully assembled node in the way we had hoped. To fix this, Neha and I went back to the PCB room in techspark to make another attempt at doing our own fabrication with our new design. While the fabrication seemed to go well, Neha did run into an issue when soldering our components onto the board: the PCB seemed to melt. I would guess that there must be some way around this issue, but the delivery date on the new PCBs was moved up to May 2nd, so we may be able to use these for the expo instead.

Another aspect of our project that I worked on this week was developing some code that would allow us to sleep our ESP32 to conserve battery power. After a little research, I was able to find that there was a fairly simple way to do this and it seemed to work. However, because our LCD display is powered by the same rails that the ESP32 is powered on, sleeping the ESP32 will not turn off the display. To remedy this, I did some research into the Nextion commands and found that I could send a command to the Nextion display to sleep the screen. After this, I wrote a couple of wrapper functions for this so that they could be called in our main function and this worked successfully. To test this, I set up a circuit that ran our display and an LED from the ESP32. I then attached a multimeter to the circuit to measure the power draw. When the display turned off, the current decreased from ~150mA to ~40mA and then when the ESP went into sleep mode, the current decreased even further to ~10mA. This test is shown in the video below:

https://youtube.com/shorts/vVrOd6ty3pc?feature=share

Currently, the PCBs are a little behind schedule. This is because we needed to reorder the PCBs. However, if they do come by the date that they say they will, we will be able to solder them and have them working by the techspark demo. If this is not the case, then we will plan on soldering our components into protoboards so that we still can still have compact, finished looking nodes. In terms of software, Jason and I split up the power sleeping and distributed pathfinding. I was able to get the power saving software to work so this fits well into our schedule. We also still need to complete our video and poster, but this will happen once we have our system finished. 

In the upcoming week, one very vital thing for us to get done is the PCB assembly. As soon as the PCBs arrive, assembling one of these complete nodes will be Neha’s and my priority. Another thing that I am hoping to achieve is to integrate the power saving code with our current display/pathfinding integration. I don’t think this will be too much work, but it will be important to ensure that the delays caused by sleeping do not mess with our pathfinding algorithm and that we can turn off the power saving once a fire is detected.

Posted on

Jason’s Status Report for Apr. 22, 2023

This week I started on distributed pathfinding, only paying attention to packets received by immediate neighbors of each node. This ended up essentially being an entire rewrite of the pathfinding code that I currently have, and therefore it has taken longer than expected to get it finalized. Rather than actually calling code to run Dijkstra’s algorithm or A*, each node is instead waiting for a response from any of its neighbors, to see if one has a path to an exit, and if so, what the distance is to it. When it receives such a response, it will note down the weight to this exit and broadcast that information to any of its neighbors. If the node receives a new shortest path, or information that the current shortest path is not invalid, it will update the path it is taking, and forward that information onward.

I also modeled a very basic idea of what I think our demo room should look like:

(this is a section view of the model)

I thought this was a decent model because it was two stories, has multiple rooms on one floor, multiple exits – there is one on the back of the model as well – and has room for 5+ nodes; it seems like this model would allow us to demonstrate a lot of the functionality of our project during the demo. This should be simple enough to make, as I have access to a significant amount of leftover material – including fasteners and tools – now that booth has been completed and torn down.

I also worked on finally getting the display integrated with the current pathfinding implementation that I have. Aidan and I have been talking about this integration for quite a while at this point, but I finally sat down and got it working. This was a relatively small integration, as all the code was already written, I just needed to import his helper function files into my code and call them; while it was a relatively small amount of effort to integrate these portions, it does represent a big step, as it officially confirms that we are able to link the pathfinding code and the display code. 

The final thing that I worked on this week was the final presentation. I am going to be the one presenting this time, so I have been spending time going through the presentation requirements making sure that we address all that we need to. I have also been touching up the diagrams that we have, and reviewing the feedback that we have received from the other presentations. Finally, I have begun rehearsal so that I am calm and confident when presenting. I am also trying to ensure that I don’t rely too heavily on talking about where we would like to be in a week, but focusing on where the project is currently and the progress that we have made. 

I am slightly behind pace according to the Gantt chart tasks I have for myself, as I was scheduled to have distributed pathfinding completed by this point. While the current pathfinding implementation is perfectly suitable for a demo and final presentation, we wanted to implement the distributed pathfinding approach, as it is much more scalable for a real-world system; it significantly reduces the computation done on each node, and greatly reduces the range as each node only needs information from its neighbors, and not every other node in the network. The primary reason we wanted to test it is because of the concerns with added latency. While I don’t believe I will have this implemented by the Final presentation on Monday, I do believe that I will have the time to get this completed by the final demo occurring during finals week.

Next week, I want to finalize the distributed pathfinding and test it against the normal pathfinding. I also am going to work with Aidan and Neha integrating the hardware components, and soldering all the parts to the PCBs that are currently being manufactured. I will also be working on getting the video submission, and poster finalized, and building the test building that we will be using for our final demo.

Posted on

Team B8 – FireEscape’s Status Report for Apr. 22, 2023

This week we spent the majority of our time on PCB design finalization. We made some design changes with regards to ordering an MQ-02 sensor with a built-in breakout board as well as a potentiometer to ensure that we wouldn’t have to waste time recreating this circuit on each node. We also added the possibility of powering our board with a barrel jack and ordering a plug to show how when attached to a wall, we would be able to power our nodes when they are not just running on the batteries. We also started working on our final presentation slides and cleared up some concerns with regard to the content of the presentation and we are now working to reformulate it in a manner that we can show off the progress we have made up until this point despite being able to keep working on it after the presentation. 

One of our major risks is ensuring that the PCBs come in time and are wired correctly. We have spent a lot of time this week connecting with Quinn and learning how to use the Voltera to make our own PCBs which we started two versions of but had to edit due to the trace width or spacing between holes/pads as the conductive ink tends to spread when the probe moves. Even then, the machine doesn’t have big enough drill bits for our mounting holes so we had to order that which means we can only clean up and finish our PCB on Monday. Quinn was nice enough to order our PCBs on Friday through JLCPCB in order to have a backup plan using a design that Aidan and Neha spent a lot of time checking for correctness. Though we are hopeful that it will work as intended, we want to be able to anticipate it not working the way it should, in which case we would need to edit the design and send them out to be fabricated once again despite cutting it close in terms of time. We are also considering the possibility of using solderable breadboards to get a slightly more finalized version if all of our PCB fabrication attempts don’t work out. 

One other risk is finding the correct voltage for our wall power supply. We know that we are able to use at least a maximum of 7V on the 5V rail of the ESP32 and we need at least 5V to our batteries after the diode and resistor in our circuit. This means that we should be able to get a high enough voltage to our batteries, but we still need to find what value we will use.

The only change we have to our schedule is that we had to push back some of our deadlines such as the poster, video, and creating the shelf for our demo. In hindsight, it was probably a mistake to schedule these as early as we did because we need to have a working product before some of these tasks. However, we feel that we will be able to finish them soon and before the actual deadlines, so rather than actually changing our schedule, we will just catch up in these areas. We also received notice that we have been invited to present our demo at the general CIT presentation, in addition to the general ECE one, which has moved up some of our deadlines, but we still believe that we will have enough time to get it all done. After this upcoming week ends, most of our schedules clear up, allowing us to dedicate more time to get things finalized.

Posted on

Aidan’s Status Report for Apr. 22, 2023

This week I spent the majority of my time getting the PCB design ready for shipping. In order to do this, we first had to make some fixes to the battery circuit and power supply. Last week Neha and I realized that we would not be able to charge the batteries up to 5V with a 5V power supply because it passed through a diode and a resistor which caused a voltage drop. After some testing, we found that we were able to increase the input voltage to at least 7V without damaging the ESP32. From this, we can see that we will be able to use a high enough voltage so that we can still charge our batteries. 

After this, we had to find out how to power our board, and after some research, I decided on a barrel jack that we could solder into our pcb. We are still determining what the output of this power supply will be, so to accommodate for this, I added in two resistors to our PCB design that can act as a voltage divider to ensure that the voltage that we are getting into our main circuit is the right level. After this, there were some other issues that had to be fixed on the PCB. One of these is that we were having trouble with our eagle library file for the temperature sensor. The metal pads were overlapping, so I had to place three holes instead. I also had to reroute all of the traces that were under the ESP32, because the machine we were using was not precise enough to lay traces between the pin holes of the ESP. 

Once the PCB design was finalized, our hope was to create a version ourselves so that we could test it before ordering more online. However, after Neha spent Friday making a PCB with Quinn, we felt that we would not have time to clean up the board to test it, while still ordering the PCBs on time. One remedy that we tried was to use the Bantam machine to see if we could mill a PCB design that we could use for testing, but we had trouble getting the settings right, and we thought that this would also take too long for us to do testing before ordering the PCBs. Finally, Neha and I decided that we would spend time verifying the PCBs and then we would order them. To do this, we wrote out the entire design on a white board system by system and went through each system to make sure that it was wired correctly. In doing this, we were able to find a couple mistakes that we fixed. After this we sent in our order to Quinn to be placed.

Final Design:

Currently the PCB progress is on schedule. We were hoping to have the PCB design sent out for fabrication by now, and we have finished that up. Ideally, this means that we will get the PCBs back this week and we can start assembling them soon. One thing that we are a little behind on is the distributed pathfinding. We have not been focusing on this too much, because we had to get the PCB design finalized, but now that this is done, we will be able to spend more time on the pathfinding and finish this up. We are also a little behind on some of the aspects such as making a video demo and a poster, but I feel that we will be able to finish these tasks once we have our system up and running.

Next week, the first thing that I want to do is to work with Jason and Neha to do our final presentation slides. After this, I want to work with Jason to get the distributed pathfinding completed. Additionally, the PCBs should arrive before the week is over, so I am hoping to start assembling those and placing our components onto the boards. The one other thing that I will do this week is select a power supply and have it ordered so that we can show that our circuit works with wall power and that it charges the batteries. Once we do this, we can also determine the resistors to use in our voltage divider.

Posted on

Neha’s Status Report for Apr. 22, 2023

This week we spent the majority of our time on the PCB design and fabrication. Earlier in the week, we made the decision to order MQ-02 smoke sensors that came with a breakout board. This is because originally, we thought that because we figured out how to read from the sensors we wouldn’t need the additional breakout board and thus, could directly attach the sensor by itself to our PCB. However, upon more research from last week we realized that if we wanted to control the sensitivity of the smoke sensor, we would need a potentiometer. There are smoke sensors that come with breakout boards with a potentiometer for this reason, and if we just had the smoke sensor on its own then we would have to build a new circuit which included a combination or more resistors, diodes, op amps, and transistors which we realized a) we would be making up the internals of the breakout board and b) it wouldn’t make sense do do seven times for each PCB that we were fabricated. Based on this, we placed a new order of smoke sensors which should be arriving Monday and we already know how to set it up which is great. 

After our weekly meeting with Professor Mukherjee and Kaashvi, we found out the Quinn, the lab technician, was learning how to use the Voltera machine in Techspark that allows us to make the PCBs from scratch. Immediately after this conversation, we reached out to him and he let us send over an initial PCB design that he got started on. On Thursday, we found that some of the holes in our design were too close together resulting in the conductive ink joining pads that otherwise shouldn’t have been connected. Aidan worked to quickly fix these issues and we sent over another design. On Friday, I met with Quinn to learn how to use the Voltera and he walked me through the process using our new design. While the front of the board printed well, there were multiple issues on the back regarding the conductive ink flow. It was not being calibrated properly and a lot of the traces ended up being too thick and the conductive ink would get dragged across the board forming connections that we shouldn’t have on our board. While we didn’t have the right drill bits for some of our bigger holes, Quinn promptly ordered them and I will be going back in on Monday when they arrive to finish the PCB we made and clean up the incorrect connections. While this was a time consuming process, we greatly appreciate the effort Quinn spent with us and we hope that we can make a PCB using this machine sometime next week. There are just a lot of steps that can go wrong, the biggest being the act of controlling the flow of the conductive ink so that it is precise. While it would be difficult and time consuming to do all 7 PCBs in this manner, Quinn helped us place an order through JLCPCB with our updated PCB design which should hopefully come in next week. I have attached pictures of the Voltera at work below.

In an attempt to see if we can find another way to make our PCBs in Techspark, Aidan and I tried to learn how to use the Bantam milling machines as shown below. However the material we had was copper with the middle non-conductive layer so essentially the mill would etch away and leave the copper in the places where the traces lie. We experimented with this for a while after downloading the corresponding software and attaching our Gerber files but we couldn’t find a way to ensure the machine would etch the excess copper away instead of tracing out the exact circuit. 

We have also started working on the slides to prepare for the final presentation next week. This weekend and in the upcoming week, we plan to work on the slides and incorporate components that we have gotten working from the interim demo and beyond. When the smoke sensors come in, early next week, I hope to quickly test them and find a working threshold for fire detection. When the PCBs come in next week, Aidan and I plan to test each sub circuit and confirm that our PCB works as intended or quickly make changes as necessary. With regards to the Gantt chart, I am feeling a bit more pressed for time despite actually being on schedule given that we already sent the PCBs for fabrication and next week will be all about assembling the board and testing its correctness but we will have to act quickly if things don’t go as expected.

Posted on

Team B8 – FireEscape’s Status Report for Apr. 8, 2023

This week we had our interim demo which we believe went pretty well, and we hope to keep moving forward with integration between more of our individual components. Earlier in the week, we spent a lot of time doing initial integration for the sake of our demo where we were able to create a fixed path and broadcast which node had detected a fire and what that meant for the rest of the nodes in the path. We were able to recalculate a new path based on that fire-detecting node and once the fire was no longer detected, we were able to change back to a different path. We also had integration between the LEDs and the displays, as we were able to display directions and a highlighted path based on a hardcoded set of nodes and edges. We hope to be able to move away from this hardcoded testing to be able to incorporate real smoke and temperature data and have the paths reroute. 

Our risks continue to be integration between separate, individual components as well as the PCB fabrication that we are still trying to finalize the details on. Our current plan of action is to reach out to Brandon Gonzalez, a student of Professor Carley’s, that has worked with this area before to gain some insight and hopefully move forward with the fabrication of our own PCBs. However, we don’t want to get too stuck on this and spend too much time so we want a backup plan of either generic solderable protoboards or just using JLCPCB to send one out in parallel to us trying to figure out how to do it ourselves. One other risk is that our PCB is looking like it might need 2 layers. This would increase the complexity of our PCB and may make it harder to manufacture on our own. This may encourage us to look into shipping.

One small change that we made is that we are no longer planning on having power going from the wall to a jack on our PCB. This was our original plan, but we realized that this was very unnecessary due to the fact that the ESP already has a micro USB port that we can use. This way, we can just allow our PCB to be driven by the 5V pins on the ESP32. Another smallAnother change is the number of batteries we may be using. Originally, it seemed like we were going to use 3 batteries for the LED nodes and 6 for the LCB nodes. However, after testing, it seems that we may be able to use 4 for both of these. It also seems like we may not use the 3.3V pin to power our ESP32 because we were having trouble getting this to work, whereas using the 5V pin worked well.

For our interim demo, we also made some Gantt chart edits that involved pushing the PCB fabrication and design further back as well as adding in some more achievable subtasks by breaking down bigger items to be able to make more progress toward our final demo.

Posted on

Jason’s Status Report for Apr. 8, 2023

This week, I focused on prepping for the demo. I mentioned in last week’s status report that I had worked on refactoring the code for pathfinding so that it could be interfaced with in the .ino file that holds the entry point to the software stack. When integrating the newly refactored pathfinding code, I realized that the Arduino code needed a refactor just as badly. I ended up completely restructuring the file into individual helper functions that either perform some setup functionality for the pathfinding or hardware or perform a task, such as reading the sensors or performing the pathfinding operation using the retrieved data.

The refactor helped significantly with keeping the code organized and manageable while I was integrating the pathfinding tasks. One of my oversights when writing the pathfinding code is that it would need to be run in intervals, continuously. It also shouldn’t run the costly setup code where the graph is initialized and all necessary memory is allocated. When I had originally been testing the pathfinding code, it was only setup and run once, so when trying to include this in the Arduino file, there were errors due to freeing memory which should have persisted for the life of the program. Additionally, some of the code was making destructive modifications to the graph data structure, and because of this, after a certain number of runs of the pathfinding code, the output path would no longer be correct because the original weights of the edges had deviated too far from their default values. As a result of this, much of the logic had to be changed to use additional data structures, and passing copies of data, rather than references to the original data structure which needs to maintain its initial state.

After the debugging had been finalized, all I needed to do was change the packet contents slightly and include a few additional checks before I was able to output the shortest path from each source node to an exit, updating in real-time based on responses received from other nodes, and their reported temperatures.

This upcoming week, I want to finalize integration with Aidan’s display code. Seeing as we both had functioning demos of our respective parts during the interim demo, with me outputting a path as a list, and him receiving a list as input and using that to display a path, this should be a relatively simple integration between our pieces of code but does require us to schedule a time to meet and test it. I also want to work on adding low power mode, as this will likely be required to reach our target of 24 hours in passive mode, and 5 minutes in active mode without hardwired power. Finally, I would like to begin switching to distributed pathfinding, where each node receives only computes pathfinding based on information received from its neighbors. 

As for verification, I would like to do a significant amount of edge case testing where we ensure that the path always avoids errors and unsafe nodes. I would like to generate some test graphs using Python if possible and run the pathfinding automatically, logging if a bad path is ever found. Additionally, I would like to test the range of the ESP-NOW networking and check to see what happens if there is enough signal degradation that the node ID or sensor data is reported incorrectly. This will mostly involve running the same code as the demo but increasing the distance between each node to see if we correctly handle it. 

As for progress, I am on track with my Gantt chart and believe I am in quite a good position for the capstone: we received positive feedback after the interim demo. I have added a few tasks that had been left off, such as low power mode, and distributed path-finding code. I had forgotten to add these tasks, as I was focusing on reaching a minimum working demo, and these are complex additional features that didn’t show a base functionality but still need to get done.