The most significant risk is the integration of hardware, mechanical, and software. We will be working on this together tomorrow as our individual components are either done or in the debugging phase.
For testing, we will be first testing individual processes, running trials on each component (ie. schedule signal generation from software app, sensor detection integrity/accuracy from the circuit’s end, and door opening accuracy for mechanical, etc.). We will be putting all of our individual testing results into a google spreadsheet and calculating the average accuracy. As of right now, the idea is to organize our results into quartiles so we know which aspect to focus debugging/improving first. Nothing has changed from this initial testing idea other than us recruiting our fellow classmates as well as some professors for user-testing. We will also decide on the handicap to best simulate our testing once our implementation is functional – this will be included at the very least for our final report.
Changes made is that 2 ESP32s will be used should the debugging be unsuccessful with one by tomorrow, as that appears to be the main issue, with the second ESP32 being powered by Vin instead, with mitigations being handled by handling one issue at a time so no components are accidentally damaged.
Our schedule is around the same.