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.