Posted on

Team B8 – FireEscape’s Status Report for Mar. 18, 2023

At the moment, our most significant risk to our project is going to be the integration of all our independent systems. We have been working on the pathfinding, displaying on the LCD, networking, and sensor detection all in isolation. With the demo occurring in two weeks, we will need to really focus on getting each system into a reasonably finalized state so that we can work on integration between all independent parts. This will also require a lot of joint time spent between the owners of each technology so that we can get each of the systems properly meshing. 

To try and mitigate this risk, we are doing our best to have each of our systems in a working state prior to this upcoming weekend to leave ourselves with at least a week to work on integration. This would require all of the sensors arriving quickly and being promptly tested, finalizing the pathfinding code and backup battery circuit, and being able to build graphs based on inputted floor plan examples. Currently, one of our biggest challenges is networking and being able to get our individual ESP32s to communicate with one another and show that we are properly being able to transmit and receive data. As our optimal path depends on smoke and temperature data from each individual node and being able to share this information amongst each other, we need to make this a priority. For the sake of our demo, we are just going to be using breadboards instead of the PCBs as we would want to test that our integration works before finalizing with a PCB. We realize that we have many complicated moving parts and we need to get working on integration as it will be pretty challenging especially with the initial demo coming up quickly. We will be spending a lot of time outside of the mandatory lab to work as a team to get these tasks done especially knowing that this week we don’t have our weekly professor/TA meetings and we are dedicating Wednesday’s mandatory lab to the ethics lecture and discussion section.  

One of the biggest changes that we made to our design this week is that we have scaled down our design from using 10 nodes to using 7. We were running up against our budget and decided to return some of our parts to the ECE store to have some more flexibility in our budget. We feel that 7 nodes will still be enough to be able to demonstrate the path planning and other features that we are working on. Another design change that we are considering is switching from ordering PCBs to making our own. Because our PCBs are going to be fairly simple, we feel that we may be able to make these ourselves. This is something that we will be looking into.

While there are some places that we have fallen behind in our schedule, we have not decided to adjust these in our schedule because we are planning on making this progress up next week. We feel that our schedule is still feasible and that it allows us good pacing for our project.

Posted on

Aidan’s Status Report for Mar. 18, 2023

One of the first things I did this week was my ethics assignment. I felt that this assignment was helpful because it focused on some of the less obvious impacts that engineering projects can have. For example, at first glance I would not assume that a highway infrastructure could have political implications. This assignment helped me to see that ethics goes beyond power consumption, pollution, etc., and can be less obvious but still very impactful. I also had the opportunity to look into some statistics for generative artificial intelligence that I found very interesting.

There were some parts that we had to order this week, so I ordered the batteries that we needed. We decided to scale down the amount of nodes that we are planning on using, so this also helped us save on the number of batteries that we had to order.

After this, Neha and I spent time working to get our display working. When we first received this display, we were all at a loss for how we were supposed to program it. Initially, we thought that, because there was an application that we had to install on our laptop, we would just plug the board into our laptops and program it through this application. However, then we realized that the adapter for our laptop only supported the board with power, so we knew there had to be a different way. After researching some tutorials, we found that we would create the display code on our laptops, and then upload it to a micro SD card that we could then put into the display. After this, we were able to get a picture of a floor plan showing on our display, which was one of the main things that I wanted to get accomplished this week. After this, Neha and I researched how we would interact with the display through our ESP32, and we found that we would be able to set state variables through the TX pin on our ESP32. We worked at this for some time, but were unable to get it working. We’re planning on working more on this next week.

Another thing that I spent some time working on this week was the communication between ESP32s. I found a tutorial online for connecting two ESP32s through an Ethernet connection. After spending some time working on this, I feel that I will need to do some more research for it in order to get it working. I was able to get the code compiled and uploaded, but for some reason the microcontrollers were unable to begin the TCP connection.

This is the tutorial I was using:

https://esp32io.com/tutorials/communication-between-two-esp32

Getting something to be uploaded to our display was one of my main goals for this week, so finishing that was on schedule for me. One aspect that I have fallen behind in is the network communication. However, I know that Jason has been working on this as well and has made some progress. I feel that this week we will be able to make up for this work. I do not have many tasks in the PCB area right now so this should give me more time to work on the network tasks.

This coming week I would like to get the communication working and have messages sent between the nodes. I would also like to get to the point where we can change what is shown on the display based on our sensor readings. One other thing that I would like to complete next week is to write the message code for my distributed path planning software. This will rely on us having a good understanding of the wifi communication, but I feel that this is something we will be able to do this week.

Posted on

Neha’s Status Report for Mar. 18, 2023

Earlier in the week, I spent a lot of time working on the ethics assignment. I thoroughly read each of the two articles and dedicated effort to answering the required questions carefully. Then I reflected on the questions that we had relating to our project. Beyond just the ethics assignment, I wanted to ensure that I got the rest of the hardware we needed such as the remaining temp sensors, smoke sensors, and batteries since we made some minor design changes last week. The forms have all been sent out and approved and they all come from reliable suppliers so we anticipate for them to come in sometime next week.

Beyond just the logistics, Aidan and I spent a lot of time trying to figure out how to program out displays. Like I had mentioned last week, the Nextion display software can only be run on a Windows machine so we knew that we were going to have to work together. Earlier in the week, we were having difficulty figuring out how to interface with the code so we made a plan to keep researching separately and then set up meetings throughout the week to try what we had researched on the side. Yesterday, we were able to display a floor plan image of Wean on our display. At the beginning of the week we were unsure how we would be communicating with the display through our laptop as well as the ESP32 knowing that the microcontroller would be the one powering the display. After some more digging around, we found that we need to place the build file in micro sd card that is stored in the display board. The build file would also contain the image that we want to show once it is placed in the Nextion program. After, we power the display with the micro sd, we learned that we would then need to power it off and remove the sd card and restart for the image to be outputted to the display as shown below.

We wanted to keep experimenting with being able to interface with the display by writing code that would programmatically determine which image to show. In our test case, we wanted to be able to simply flip between two sets of images. We had found an example use of an ESP32 interfacing with a Nextion display while collecting various weather related data that would determine what image to show on the display. We altered this code a fair amount to simplify it for our test case, but we unfortunately were unsuccessful in getting the desired outcome of alternating images on a timer. We hope to keep working on this because for the sake of our project, within our pathfinding code we would need to be able to source through images of potential paths where the Arduino code would return some set of indices that are equivalent to the best path and have these indices relate to the image to display. Furthermore, to implement our complex design it would require more experience with the Nextion display software in terms of utilizing their other features besides images that could be of value to us when highlighting the best path on the image. 

In the upcoming week, I would like to keep experimenting with getting familiar with programming the display and continue the test case we started with. If the smoke sensors come in next week, I want to start testing them and see what the range is like for placing a candle in its vicinity. Furthermore, because we ordered just one breakout board just so we can figure out the pin layout for the sensors, I want to test with and without the board as eventually we will be moving toward PCBs in which case the breakout board for the smoke sensors will be unnecessary. That being said, I want to make more progress on my Eagle research or look into what Professor Mukherjee had mentioned about making the in house PCBs with the copper boards during our weekly meeting this week. 

I am a bit behind schedule in terms of working with Jason to receive and handle messages from the pathfinding. We are behind on a bit of the networking aspects like talking between nodes and being able to send alert messages to other nodes. With this, we are going to push these tasks to the following week and make them a priority as these are the first step in integrating our multiple moving parts to be able to work together. 

Posted on

Jason’s Status Report for Mar. 18, 2023

At the beginning of the week, I was working on the ethics assignment, reading the two papers that were assigned. After I had finished that, I began focusing on implementing network communication between two nodes on the same network. All development testing that we had done on the ESP32s thus far has been on either Aidan’s or Neha’s computers, so I had to work on setting up the Arduino IDE to interface with these boards. One unique thing that I had to deal with though, was that my drivers were installed incorrectly. It took a while to sort out but I had to go to SiliconLabs website and install their CP210X USB to UART drivers before my computer would recognize the ESP32s. After doing that, I was able to download to the boards as expected. 

After running a HelloWorld-type programming to ensure everything was working as expected, I began working on setting up each node’s network connections. Something that I overlooked, which caused me a bit of trouble at the beginning was that I was trying to connect to my main WiFi network; this was an issue because while there are some ESP32 models that can use the 5GHz frequency of WiFi, the C3 – which is the model that we have – can only use the 2.4GHz frequency. Once I realized that I quickly set up a 2.4GHz channel on my router, specifically for IoT-type devices, where the nodes could be isolated from the rest of my network and talk to each other.

Once I got the nodes connected to the network, I could verify their MAC addresses on my router’s interface, and use that information to establish a connection between the two nodes. From that point, I wrote some test code to verify that I could correctly send information between the two nodes, so long as I have each of their MAC addresses, and they are on the same network.

I was slightly behind last week and needed to focus on integrating communication over WiFi. I now have that implemented but at a very rudimentary level. Currently, to get two nodes to talk, their MAC addresses need to be hardcoded into the file and sent directly to this address over the shared network. This implementation has issues, for example, if that MAC address is no longer on the shared network. I technically accomplished what I sent out to as per my last Weekly Status Report, and am on track with my Gantt chart plans, but I would like to improve the usability of the current implementation of the network connections.

Next week, I want to make make the data transfer a bit smarter: rather than relying on hardcoding the individual MAC addresses, I would like to try and figure out how to recognize all of our ESPs that are on the network, add them to a list, and broadcast to all of them automatically. This would avoid the manual setup and would be important if this were to actually be a viable product. I also want to look into using ESP-IDF rather than Arduino IDE. It seems that there are some additional features available there, as it is actively developed directly by Espressif, whereas, when we are using Arduino IDE, we are limited by their update schedule to support some of these features.

Posted on

Neha’s Status Report for Mar. 4, 2023

This past week our team has spent the majority of time working on our design report. We realized that in writing our sections, that some required a lot more detail and consideration than others. For example, we wanted to ensure that we had a thoughtful trade studies section as we had iterated through multiple design choices and we wanted to explain our thinking process behind those decisions. We also wanted to work on improving based on the comments we received from our design presentation with regards to describing the 2 MVPs: the LED nodes and LCD nodes as well as working on improving our block diagrams. We also knew that because we have a lot of moving parts, we wanted to be specific about our system implementation and testing sections so we spent extra time there. 

Beyond just the report, I worked on interfacing with the ESP32. When doing a lot of research on the best ways to program, it was actually recommended to utilize the Arduino IDE. This made it a lot easier and decreased the learning curve. I also researched other IDEs that are compatible with the ESP32 so we have others that we can use, but because our team has the most experience with Arduino, it makes the most sense to start there. It took a little bit of time resetting and rebooting the ESP32s to be in the correct mode but once I got past that issue it wasn’t too bad. I made documentation on setting up and using the ESP32 for the first time so that the rest of my team can follow those steps without difficulty. That is something we are trying to work on as time is making good documentation for issues that we run into so that we can save our other teammates time in the future and not waste time on repeating the same mistakes. Now that I was able to set up the ESP32, I tried to collect temperature data once again but this time with the ESP32 as our microcontroller instead of the Arduino. Attached we have a photo of how we wired up the board to our temperature sensor. 

We also received our displays last week and wanted to start interfacing with them as soon as possible. When Aidan and I were doing research on how to program them, we found that the software necessary is only available on Windows. Because I have a Mac, I might need to look into virtual machines or just work together with Aidan to ensure that we are able to figure out how to wire it up and work with them quickly. We also decided to use MQ2 sensors for our smoke sensors. We received them last week as well and they are not quite what we expected. They are a lot bigger and unfortunately, do not even have a datasheet to know which pins are what. We found its use in one circuit which makes use of another chip so either we figure out if we need to order those chips as well or just use a reliable MQ2 sensor that we will order quickly so we can test and implement them into our nodes. 

In the upcoming week, I want to figure out how to program the display and figure out what pins on the ESP32 are necessary to do so. I want to be able to get more comfortable with using the display so when it comes to integrating the pathfinding instructions, we can do so without so much difficulty. I also want to ensure that we order the rest of our temperature sensors and smoke sensors by Monday because we really need to start interfacing with them and building our nodes. I also want to utilize the LEDs to experiment with how we want to display our path directions and use the ESP32 to specify arbitrary NESW commands that reflect what the LEDs are doing. With all of these separate hardware components, I think it would be great to start planning our the PCB design as well or at least start designing it and learning more about Eagle.

My schedule was a bit pushed back as well due to the design report and I am mostly on track except for being able to figure out how to output to the display. In this task, I am a bit behind. This task will be a huge priority in the coming week in order to get back on track and not cause any more delays.

Posted on

Aidan’s Status Report for Mar. 4, 2023

This week, I spent the majority of the time working with Jason and Neha on our design report. One of the contributions that I made to this report was the implementation details. Here I provided more specific details that added onto our system architecture section. Additionally, there were sections that we all worked on together. Also, putting this design report together forced us to make some decisions that we were wavering on, such as the batteries. I feel that, now that we have finished this report, we have a much better sense of a concrete direction that we will be proceeding in. Now that our design is complete, we will be able to focus on creating the systems involved in our project.

 

One decision that I made while we were writing our report was to switch out our batteries. Originally, we were using LiPO batteries with a capacity of 1000mAh and a voltage of 3.6V. However, after more research into the power consumption of our displays, we found that this voltage would not be high enough. We had previously assumed that this capacity would not be enough, based on our calculations, but now that we also found the voltage would not be high enough, we felt that we needed to pivot our choice to a different battery. I found that we could use NiMH with a voltage of 1.2V. After spending a decent amount of time researching the possibility of continuously charging LIPO batteries, I could not find any documentation about a safe way to do this. For  NiMH, I was able to find this information very easily, which made me much more confident about the ability to continuously charge these batteries. We found these for a cheap enough price to stay in our budget, and by using 3 of these batteries for our LED nodes and 6 for our LCD nodes, we would be able to successfully power our nodes. Additionally, the capacity of these batteries is 2000mAh, which satisfies our battery capacity requirement.

 

Lastly, I also spent some time getting started with our displays. First I downloaded the software required to use these displays. Then I began doing some research on how these boards are programmed. These are the sites that I found and am planning on using when I begin to use these boards:

https://www.instructables.com/Nextion-Display-Interface-With-ESP-32-Four-Relay-B/

https://anywarellc.com/2020/12/29/nextion-touchscreen-with-esp32/#:~:text=Nextion%20has%20a%20nice%20series,to%20support%20HMI%20GUI%20development.

https://www.nutsvolts.com/magazine/article/building-a-programmable-thermostat-with-a-nextion-lcd-display

 

My schedule was pushed back slightly because of the design report. This took more time than I had previosly thought it would, so I was unable to get to programming the displays. However, there are no current tasks that are blocked by this. I am planning on finishing this task this week, and this will not cause any further delays to our schedule. We also do not have the boards communicating yet, which is behind schedule. However I also believe that we can accomplish this task during this coming week as well. Last week, I had multiple midterms, and this along with the design report occupied much of my time, but now that these are over, I am confident that I will be able to use the extra time to catch up on this work. Next week, I am also planning on working with Jason to get the Zigbee network setup, assuming that the zigbee cards have arrived. Lastly, I also plan on getting a couple of our ESP32s running on wifi, so that I can test out the distributed pathfiniding code that I have written for them. This week, I am also hoping to get some testing done with real fire from a candle to further test our sensors.

Posted on

Team B8 – FireEscape’s Status Report for Mar. 4, 2023

This week, we spent a lot of time working on our design report as a team. It was a big team effort as it involved a lot of special considerations and thoughtful explanations. We wanted to ensure that we were addressing the concerns from our presentation and working on the feedback provided to us. Beyond working on the design report, we each had individual tasks to complete based on how we divided the work of the project which is provided in detail in our individual updates.

The most significant risk that we are facing right now is making sure that we receive the hardware in time to take into account the integration time. We have not yet received the XBee modules that we are planning to use to enable our ESP32’s to communicate over ZigBee. While this is not going to be the primary mode of communication for our node system, we still need them to provide a proof of concept. Seeing as none of the members on the team are familiar with using XBee modules, or the ZigBee protocol, we are worried that their delayed delivery will make integration an issue for the interim demo that is occurring on April 3rd. To plan around this, we are making sure to work on development for WiFi, as that is already implemented on the board, and is the primary mode of communication we actually plan to use for our demo.

We have not had any design or major gantt chart changes in the last two weeks. We had anticipated extra time dedicated to our design report which might have gotten in the way of tasks necessary for the project building itself. Our gantt chart specifies that we should be focusing on getting nodes to communicate with each other over a network, but the type of network is never specified; initially, we had intended for this to be about ZigBee, but this task is now referring to WiFi. Furthermore, in regards to the design not changing, we do intend to keep smoke sensors as part of our node structure. However, we are now looking into changing our original smoke sensor to a more reliable and well documented MQ2 sensor which we need to place an order for by Monday so it can come quickly in order to get well acquainted with it. While the implementation of the task has changed, the task itself has not been modified, and no updates to the Gantt chart have been made.

One of the new tools we must learn that is necessary for us to complete our tasks, is the software used to create an interface on the displays that we ordered. These displays use their own software to establish a general layout template, and then update with information that is passed into it. We will need to learn how to make a template that will match either a floor plan or a set of instructions, and then update it depending on what information is being passed to the display from the pathfinding calculation done in our software. This software seems relatively simple to use – it claims to be drag and drop – but it is another step that we will need to address during the testing and integration phases. Another tool that we know we will need to become more adept with is Eagle. Right now, we have some experience, but in order to successfully design our own PCB, we will need to become proficient. As our hardware pieces are coming in slowly, we are able to figure out how each individual component will communicate with the ESP32 and from there we can plan our PCB that takes into consideration all of our individual components to work simultaneously.

Posted on

Jason’s Status Report for Mar. 4, 2023

This past week I focused on working on the A* version of pathfinding, touching up the code to include additional information that will eventually be necessary during implementation, and running some general benchmarks for A* vs normal Dijkstras.

Seeing as I had never used A* before, it took a bit of research to understand what went into making a heuristic function; in case anyone reading this is unfamiliar, A* is an informed version of Dijkstras, which allows the algorithm to guess what the best path is going to be by using a heuristic function written by the person implementing the function. This function will tweak the weights of the priority queue used in Dijkstra’s such the next path chosen should be favored if it is already expected to be along the current best path. Another way of phrasing it is that Dijkstras algorithm is a special case of A*, where the heuristic function is uniform across all data points. 

After having learned a bit about it and figuring out how I might write an algorithm for our specific use-case, I decided a good heuristic function would be to favor what would be the best path, assuming there were no obstructions. In the case that there are no obstructions in the graph, or there are obstructions, but they are not in the way of the best path from the current node, this should significantly speed up algorithm time.

The testing of A* vs Dijkstra’s doesn’t rely on any real-world parameters, so I was able to simulate it by running various tests where there are reported obstructions at some nodes. These are the results: 

Keep in mind that these results will vary depending on the graph that is being used for testing, what nodes are being reported as obstructed, and the weighting that is being used in the Heuristic function; that being said, I think this provides a useful insight that using A* might provide some benefit to our project, but the improvement is not guaranteed, especially if there are multiple reported obstructions. It is also important to note that A* should scale better as the graph grows because the cost of calculating the Heuristic function should become more insignificant as the time it takes to find an exit node grows. 

I am slightly behind schedule because I have not yet started wireless communication integration. We recently made the decision to use WiFi as the primary source of wireless communication for our nodes due to cost constraints; because WiFi is integrated directly into the ESP32’s that we purchased, I should be able to progress on that throughout this week. However, we still wanted to use ZigBee boards to display a proof of concept. I am unable to start on ZigBee network communication because the XBee boards that we ordered have not yet arrived. To answer the question of how I plan to get back on track, once we get back from spring break, I will have just completed my midterm exams for my other classes, and I expect to have extra time to dedicate to capstone. This additional free time should be the perfect time to catch up on some of the project tasks that I have fallen behind on. 

This upcoming week, I want to focus on getting the nodes to communicate with each other over a network. I want to focus on using WiFi first, but if the additional boards have come in over break, I want to attempt to get communication over ZigBee as well. This is going to be the main task that I want to address because it is absolutely necessary to have a working demo for the interim demo that is fast approaching on April 3rd. If there is additional time after focusing on network communication, I will begin working on sending data between the node and incorporating that into the pathfinding: the goal here is to have pathfinding update to reflect the updates sent from other nodes about what is a valid path. 

Posted on

Team B8 – FireEscape’s Status Report for Feb. 25, 2023

This week, we began by working on our design review slides. This was a team effort, and we spent much time meeting to ensure that the slides were completed. We met to ensure that we were set up for success in the presentation, and referred to Kaashvi for feedback on our slides before we submitted them. We also referenced feedback from the proposal presentation to ensure that we were not repeating the same mistakes and clarifying information that needed it. After this, most of our time spent together was during the in class presentations, so the majority of our work was completed individually.

One risk that we discovered this week is that our design essentially has 2 MVPs and needs 2 sets of design requirements. By not specifying these separately, we run the risk of having conflicting specs for our varying hardware. As a result, going into our design report we need to ensure that we are specific about what our node structure would look like for the 2 kinds of nodes and why we made the design choices that we did. We can make these changes accordingly so that our report reflects the dual MVP in order to minimize the risk of confusing our audience and users.

This week, we changed our design with respect to the original ESP32-C6s that we wanted which appeared to have the newest standards for WiFi and Bluetooth and is known to support Zigbee. While we filled out this form on a Thursday, we had to wait until the beginning of this week for the request to be sent out at which point there were no more boards left in stock. As a result, we ended up ordering the ESP32-C3s which is also equipped with WiFi and Bluetooth which arrived yesterday. From here, we would need to pivot in the information needed to interface with the boards we currently have instead of what we planned for.

We have had to make a couple changes to our schedule. One task that had to be changed is the testing of our smoke sensors. We did not have our smoke sensors yet this week, so we were unable to begin using them. For now, we have pushed this back to March 1st, as this is their estimated delivery. Additionally, we created a new task for integrating the communication with the distributed pathfinding algorithm. As this algorithm relies on communication, it cannot be tested until our communication is up and working. Furthermore, we hope the displays come in soon but in the event that they take longer than expected we would have to push the integration and testing of getting an output to display from the ESP32-C3s until they arrive.

At the moment, our teams deadlines have not been extremely reliant on each other. This means that when one of our teammates has missed a deadline, the other members have not been strongly influenced. If hardware ends up coming in later than we expect, issues that we could anticipate with overlapping tasks would be regarding the testing of the parts with having the parts integrated with the pathfinding as well as testing on a breadboard conflicting with designing and fabricating the PCBs. We will keep monitoring the tasks often to ensure that we are still able to get our tasks done if unexpected delays occur causing us to push back certain tasks more than others.

Posted on

Jason’s Status Report for Feb. 25, 2023

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.