With the initial feedback and points brought up during our design review presentation in mind, we first reviewed our design and discussed possible issues with it as well as any changes that could be made, if necessary. The main point of discussion was the implementation of the Sensor Module, specifically whether we wanted to change sensors (concerns about detection angle) or incorporate multiple sensors different to our originally chosen one, essentially changing our Senor Module design.
After deliberating and analyzing the components, requirements, and specs of our module the team has opted to stick with the original design and interface only one sensor to a NodeMcu. We plan to test and fine tune our microcontroller with our sensor in order to obtain an accurate yet simple, easily interfaceable, and properly working Sensor Module. By sticking with the original design, we believe we will be minimizing the risk of not having a working Sensor Module and not delivering on our MVP. If we need a more precise way of detecting occupancy then we can proceed with a multiple sensor approach but not before having a simple (one) Sensor Module that is functional.
Having stuck with our original design, orders were placed to obtain the NodeMcu from outside sources and the Raspberry Pi from the ECE inventory. Since the “debate” for this week was centered around the Sensor Module, no order was placed for the IR sensor, but one has been promptly planned for next week.
On the software side of the project, the initial Django web app was created. Considering the feedback we got from our peers on Monday, the team discussed ways in which we could possibly extend the scope of the web app with user experience in mind. A peer suggested that users might want a more detailed web app the went beyond simply marking occupancy in real-time and allowed the user to plan their gym session ahead of time. An idea that bounced around is providing the user with more detailed occupancy metrics using information gathered about the machines during times of day and days of the week in order to provide estimates akin to what Google does with busy times in a specific establishment. As a team, we consider that adding these features will not require any extra components aside from extending the web-app by storing, logging, and manipulating data. However, this feature is still being debated and whether we incorporate it or not will not veer us off course and delay our schedule given the nature of its implementation.
While reviewing our design, we identified potential risk areas that might jeopardize the project. The Sensor Module presents detection accuracy risks but we believe that the fine tuning capabilities and the agility that our chosen microcontroller provides will aid in ensuring this component is up to par. The main risk and the immediate challenge our implementation faces is the wireless communication between our components. Given that we will be transmitting data via Wi-Fi and using CMU’s network, congestion and inaccurate data transfer is definitely a risk that could derail our project. As a result, our contingency plan is establishing a network with components like Zigbee and other modules that ensure proper wireless communication between our sensors and the web app. Nonetheless, further research of these technologies needs to be made and experimentation with our current design needs to take place in order to asses whether the contingency is necessary. Since this would imply a major design change with added layers of costs and complexities, our team aims to refine and make our original design as robust as possible to meet our requirements.
In order to meet the goal just mentioned, we need a reliable team dynamic. Thus, we designed our testing plan with accountability in mind. This project provides a certain degree of freedom when it comes to induvial work. However, given how each component needs to be integrated we will be monitoring our team members progress via tests accomplished and metrics compiled. The IR sensor and NodeMcu need to be properly powered and wired, hence this will require collaboration between Ian F. and Nat. The NodeMcu communicates with the RPi hence that will require communication between Ian B and Nat. Nonetheless all of us need to be aware of every team member’s progress. That is why our testing incorporates both individual as well as joint tests that will inform us of the progress each team member is making.
In addition, we will use lab hours to discuss individual progress at the beginning of the session (which can be self monitored via time logs or something along those lines), work during this time, and evaluate how the schedule is going. At the end of lab we will provide each other with individual tasks that will need to be completed by an agreed upon date that follows as closely as possible the schedule we provided in the design review. This way we can be on the loop as well as keep each other motivated throughout. Of course outside communication via Slack will also be a key.
Having discussed the overall design this past week as well as established a team dynamic/plan that will be beneficial for all members, our aim for next week is to continue developing our idea with solid metrics and figures in order to provide a detailed Design Report as a deliverable for next week. Since our parts will still be in the mail for the first part of the week, it will be a great chance for us to go deeper into the specs and have everything as robustly conceptualized as possible.
