Due to the presentation that was due at the beginning of this week, a big portion of my time was spent meeting with my group and finalizing the slides and diagrams that we would be submitting. During these meetings, we came to the final consensus that we would be using ZigBee strictly for a proof of concept and relying on WiFi for the actual logic of our capstone. That decision primarily boiled down to the inability to get the ESP32 boards that we wanted – the C6s – and the fact that buying an XBee board for every node would put us over budget. We decided to use the ESP32-C3 boards instead, which, like all ESP32 boards, have built-in WiFi, and therefore allow us to conserve our budget with this new design decision to use WiFi.
I spent the rest of my time this week finalizing pathfinding in C++, ensuring that there were no memory leaks or segmentation faults. I also ensured that the output matched the python version that I had already written and tested thoroughly.
As you can see in the image above, both of the implementations match on the test graph I am using that represents Wean 5.
Additionally, on a single execution, continuous execution, or after an error, there is no memory leakage. This is key because our nodes should be able to run in a continuous state for months, and if there was a memory leak, we would eventually crash due to being unable to allocate any additional memory; this is especially true on an ESP32, and there is relatively little onboard memory for us to be able to use.
I spent a lot of time debugging the C++ implementation because I am not familiar with the language. I decided to use C++ over C because of some of the built-in data structures, such as Maps, Sets, and Priority Queues. That being said, there was a lot of syntax required to get them working that I was entirely unfamiliar with, which made it quite difficult to get compiling. I was also unfamiliar with a lot of the error messages, making debugging more difficult. In the end, much of my time was spent essentially learning a new language.
During my time debugging the C++ implementation, I decided to look into other alternatives that we could write the code in, and I begin looking into the feasibility of using Rust on ESP32. I found that there has been a lot of progress in this space, with a fork of ESP-IDF called ESP-IDF-HAL, which allows you to run Rust on an ESP, with support for the Rust standard library. Given that I have already finished the implementation in C++, it is unlikely that I will rewrite the code again in Rust, especially since I am entirely unfamiliar with the language, but if we get further into the process and I see that there might be some sort of significant benefit to using it, I might make the switch.
I also have the code downloading and running on an Arduino, and logging the correct result out over serial.
Next week I plan to try writing the code to the ESP, rather than using an Arduino for testing. Seeing as we received our ESP32-C3 order, I think the next steps should be migrating away from testing with Aruduinos and switching to using the boards we will use on our final design. I also want to try implementing A*, which should be a very minor change to the Dijkstra code; the only difference is adding a heuristic function, which aids in determining what node we visit next.
As of this week, I believe that I am on schedule with the Gantt chart tasks that I have provided for myself. I do, however, plan to insert a new task in the Gantt chart for migrating from Arduino testing to ESP32 testing, as I’m sure that will require some time to get building and running.