One of the significant risks that could jeopardize our project would be finalizing microcontrollers that fit all of our needs. For example, a lot of our time this week was spent picking parts that met different concerns like cost, reliability, compatibility with Zigbee and displays, etc. Unfortunately some of the boards we thought were most ideal haven’t even been introduced for public use yet. Our project would like to take into consideration the possibility of the wifi going out, which is why we knew we wanted to take advantage of a distributed, node based network like ZigBee. However, because some of the ZigBee cards that we have found can be pretty expensive and we have a lot of nodes, we wanted to explore alternatives. In order to make progress we decided to proceed with ESP32s and use a local network. However, because we want to take into account that the network needs to stay up, even if the WiFi goes out, we plan to order a couple Zigbee shields to show that we can make this change if necessary and explain how it would scale up. Additionally, we will explain how our system had to use only a couple Zigbee shields due to availability problems and long lead times, but that if this project was put into production, we would hopefully be able to order these parts and deal with the long lead times. This would give all of our nodes Zigbee capability, while staying under budget. This is the largest change that our design underwent this week.
For pathfinding, we are testing two pathfinding algorithms against each other. The first is a Dijkstra’s search that will work well if each node has access to the status of every other node. In the case that each node is connected to Wifi, this is a realistic scenario. Our second algorithm is a Dijkstra-Schlater search: this is a distributed Dijkstra’s search in which each node infers the shortest path from itself to the exit by receiving the shortest path from its neighbors to the exit.
Both have pros and cons: Dijkstra-Schlater would probably scale better, but vanilla Dijkstras would probably have better latency. We are planning to implement them both and do real-world testing to figure out what we want to use on our final design. We also plan to test A*, which is nearly identical to Dijkstras, but with an added Heuristic function.
Jason has pushed back his schedule by a few days to take into account some of the issues he had finalizing what hash map and priority queue implementation he wanted to use. Due to some of the slack time that was built into his deadlines, this shouldn’t impact the rest of the timeline or integration.
Our project recently has relied on 18-349, 15-210, 18-220 for our knowledge of pathfinding using Djikstra’s algorithm. Beyond these courses, we relied on a lot of external research on datasheets and tutorials of the different displays, sensors, microcontrollers, etc. We also spent a lot of research on distributed nodes and how we can run distributed pathfinding algorithms for each node so we can ensure that if a node went out we can still have an optimal path passed to a neighboring node.
One of the engineering principles that we kept in mind while we were designing our project is Usability. We wanted to make sure that our product was easy to use. When people are escaping from a burning building, the do not want to be spending much time trying to figure out our system. One of the ways that we used this for our design is that we prioritized display size. We wanted to make sure that the displays would be big enough for our user to read quickly and effectively. Many of the displays we saw had around a 1 inch diagonal, but with further research we found one that is over 3 inches. Another engineering principle that we used is redundancy. In distributed systems, it is important that if one node goes down, the others will be able to continue their tasks. For our project, we have ensured that our system will be able to survive a node going offline. This is especially important for us, as our nodes may be subjected to extreme heat. Additionally, we are providing redundancy in our sensor by using both smoke and temperature sensors.