This week I spent more time than I had intended researching ESP32’s, their different types, distributors, wireless capabilities, and considering alternatives to what might happen if we can’t get the boards we are interested in. When Aidan, Neha, and I were looking into what boards to order, I realized I didn’t know the difference between an ESP32 or ESP8266, or how an ESP32-S2 differed from an ESP32-C6 differed from an ESP32-H2. These links – a b – ended up being the most helpful in figuring out the differences between them. Ideally, the team would be able to get an ESP32-H2, because that was supposed to be the first board from ESPRESSIF (the maker of ESP32) that natively supported the ZigBee standard. The issue with the H2 is that it isn’t released to the public for general purchase yet. That being said, in my research, I realized that the ESP32-C6 surprised everyone by including ZigBee as well, and therefore was the board I let the team know I thought we should get. The issue with this board, however, has been finding a supplier with a stable inventory.
As of writing this, I just checked and saw that the ESP32-C6 Dev boards that we submitted a purchase order for has just sold out, and I will be working tomorrow on finding a replacement.
One of the other quirks that come with using some of the ESP32 boards is that they don’t all support the Arduino IDE; instead, some use the ESP-IDF development environment. There are a couple of ways to interface with it, and luckily its documentation seems to be quite thorough with a Github that provides tools for getting started developing projects.
As for the pathfinding, I am slightly behind schedule for the C implementation of Dijkstras. I spent a lot of time researching the differences between the different hash maps that are available in C. I was primarily looking at search.h, uthash, and GLib’s GHashTable. I spent a lot of time trying to figure out how to get GLib installed because it had the most functionality, helper functions, best documentation, and generally seemed to be the most performant. That being said, after a couple of hours trying to configure meson, ninja, and my general environment, and still being unable to get it uninstalled, I decided to switch to using UTHash. UTHash exists in a single header file that is available on GitHub, is still relatively performant, and is very easy to use. I think the ease of development is worth the possible performance loss. Because of my struggles with getting a hash map set up – needed for creating the dictionary representation of the graph, which maps a node to its neighbors – I was put slightly behind schedule.
I built in a couple of days into my schedule (2/20 – 2/24) for possible debugging time, so I intend to push back my Arduino pathfinding to light up LEDs back by a few days to give myself some additional time to finalize Dijkstra’s implementation in C.
I was also talking with Aidan about 2 slightly different approaches of pathfinding. Approach 1 was to give all nodes information about the entire graph, and have them complete pathfinding out entirely on their own, using temp data from other nodes. The other approach is to only give each node only information about its neighbor node, and find the optimal path based strictly on the information returned to the node by its neighbors. We think this approach might scale well but could face some latency issues. We decided the only reasonable way to test it would be to write both solutions and time which one runs faster in a real-world application, as we don’t have a good way to simulate the added latency of sending increasing amounts of data.
I also refactored my Dijkstra’s version of the code in python so I have a better reference to use when finalizing the C version. I added a bit of bash scripting for ease of testing the code as well: 
(these weights are slightly different than the actual ones I used in the code)
This upcoming week, I want to finalize my C implementation of Dijkstras, time it relative to my python implementation to check the performance difference and run valgrind on it, to make sure we don’t have memory leaks, seeing as these need to run for a long period of time without maintenance. When that is finished, I plan to set up the infrastructure to light up LED’s based on a hardcoded starting node, to indicate where to go next. Based on the way I have my code set up now, it would require very minimal changes to the structs that I am using.
I think the classes that covered what I worked on this week fit into two categories: the first category is pathfinding, which is mostly just 15-210, which is a CS class, but it covered Dijkstras in depth. The second category is writing C code, which is 18-213, 18-344, and 18-335 where I learned how to organize C projects to make them manageable, use header files properly, Makefiles, etc. I think the final class that helped would be WebApps, because that class had such an open-ended project, I had to do a lot of research, which I had to do a lot this week when trying to decide what ESP32’s to buy.