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.