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.