Category: Team Status Reports

This week, our main priority was the Final Presentation on Monday. Afterwards, Ian B. worked on the web app, while Ian F. and Nat worked on refining the nodeMCU code and worked on the encasing solution for the sensor module.

Next week, we plan on working on the final poster, final report, and final video which are due Wednesday, Friday, and Saturday, respectively. Our main priority is the final report, which we plan on starting this weekend.

In terms of schedule, we would say that as a team, we are all on schedule for this final week.

For testing, some tests we have done are:

– Web application response time – how long the web app takes to reflect going from busy to free and vice versa. We ran 10 trials on each of the sensor modules and our average findings were in our final presentation, but they were well below our initial 30s use case requirement.

– Sensor module detection – the accuracy of the sensor module while using it on a treadmill/elliptical bike. We ensured that we had over 90% accuracy as per our use case requirement.

– Sensor module power/battery life – we tested the battery life of the sensor module to ensure it met our 16.5h use case requirement.

These last two weeks our project saw significant progress in preparation for the final round of deliverables and demonstrations. On the hardware and circuits side of things, we were able to pick up on our segmented progress and create mobile and compact sensor modules. The mounting mechanism and position is proving to be challenge so this will have to be dealt with so that it does not become a limitation for our system.

Having said this, we were able to fine tune and program our NodeMcu so that it could bridge the communication between sensor and web-app successfully. At the moment, we have 4 fully functioning modules and a web-app that has incorporated features like an admin page to ease the setup process and customizability of the system. So, on the integration front, we seem to have everything working. Thus, the remaining work to be done is mostly aesthetic and consists of polishing and refining our overall product.

For next week, we must conduct more testing with the sensor modules, determine if refinements to the NodeMcu code are necessary and implement them, polish the front-end of the web-app, ensure the back-end works as intended, and develop a demo plan for the week after our presentations.

This week, Ian B. continued work on the front-end of the web application, as well as a new feature on the backend of the site for registering a new device as discussed during the interim demo. Ian F. was able to get a significant amount of testing done with the sensor module. Additionally, we now have a wireless and mobile (battery powered) sensor module, with initial steps for the encasing/mounting mechanism taking place. Nat worked on nodeMCU code, as well as spending time understanding Ian F’s work to have an idea on how to integrate it with his own code.

Next week, Ian B. will work on the final backend feature (average time spent per machine), as well as debugging and testing the new feature/existing features. Ian F. will continue working on the mounting mechanism for the sensor module, as well as integration of his work on the sensor with Nat’s.

In terms of schedule, I would say that we are on schedule in terms of the software stack with the web app. For the sensor module, I believe we should be roughly on schedule according to the new chart made for the interim demo, but it is a tight schedule as Ian F. mentioned in his individual report.

Interim Demo Schedule

This week, Ian B. worked on the front end of the web application and was able to incorporate AJAX polling so that the data displayed on the web app automatically updates/refreshes without needing to manually reload the web page. Nat was able to connect the nodeMCU to CMU-DEVICE and test sending a POST request to the web app, which successfully received the data and updated the database with the new data. Ian F. tested the IR sensor with the nodeMCU, but encountered some errors along the way. However, we plan on fixing this before the interim demo on Monday.

Next week, we plan on doing our best for the interim demo presentation, then start fully integrating Nat and Ian F’s work on the nodeMCU. Additionally, Ian B. plans on finishing work on the front end, working on the “average wait time” feature and the “Report broken machine” feature.

Overall, we would say that we are on schedule in terms of our proposed schedule from the design report. Sending data from the nodeMCU to the web app and having that data be displayed on the web page is a crucial aspect of our project which we have working, so we are proud of that.

This week, we each continued to work individually on our separate modules. Ian B. worked on the software stack, and was able to get the domain for the web app as well as get an API (send data via POST request) working in order to transfer information from the sensor module to the web app. Ian F. worked on Arduino scripts for the NodeMCU which perform calculations from the voltage supplied by the sensor. Finally, Nat worked on the POST request for the NodeMCU to get the data Ian F. calculated to the web app.

Next week, our main focus will be getting work done for our interim demo. This includes working on the front end for the web app (Ian B), as well as testing the Arduino code for the nodeMCU with actual sensor in order to send that to the web app (Ian F and Nat).

In terms of schedule, we are on track — maybe slightly behind. However, we plan on making up for lapses in schedule by working extra hard/crunching this week in order to meet expectations for the interim demo.

It is safe to say that the week before the break was a tough one for our team. Little to no progress was made on the overall project and our design report was quite poor and deficient. Consequently, we must pick up the pace individually and as a team in order to catch up with our schedule and deliver on the product we set out to do.

Having said this, some things remain constant in our design and therefore on the list of tasks we must perform for next week. Our sensor module remained unchanged from what was presented in our design report. Therefore, immediate and individual testing of our sensors and NodeMcu should take place given that the parts have already arrived at the equipment desk. with this in mind we will move to integrate these two components as soon as possible and test them together prior to interfacing them with our software stack.

Speaking of our software stack, this subsystem underwent significant modifications as part of the design report. Such changes that will affect the overall schedule as well as the communication with our sensor module subsystem. While redacting our report we had discussions about the communication between the sensor module, the backend portion and ultimately the web application we intend to develop. As a result of this discussion, we realized that the inclusion of the Raspberry Pi in our design was unnecessary and therefore added an extra layer of complexity and delay to our system. As a result, we estimate that this change will not only improve our system but also provide some much needed leeway for us to catch up and meet the goals of our overall product.

The changes to the Software Stack include changing from hosting on the RPi to EC2 as EC2 provides a reliable uptime for the web app, as well as more security for hosting over the RPi. We realized we did not have much justification for the RPi, and that an EC2 instance running Ubuntu 20.04 would work better. Additionally, the database that we used changes from SQLite to MySQL, as MySQL provides a scaleable database for the webapp and is more robust, which SQLite lacks.

With this design modification in mind, the biggest changes to the schedule involve removing the portion with the Raspberry Pi and replacing it with our new solution involving the EC2 instance and the components underneath it.

To complete this project we have identified some tools that are new and must be learned like EC2 and other AWS resources, as well as other ones which require refreshers and improved knowledge about, like possibly CAD and 3D printing software, and definitely Arduino and some of its libraries. These tools will be used individually for the most part. However, the group must actively asses and verify throughout the process that these tools are appropriate. This involves making sure that they are not too difficult to use and that the individual member responsible for them is up to the task. If we encounter that a particular tool is too difficult, we will work collectively with it or perhaps remove it in favor of a simpler one. These decisions will be made on a subsystem basis since we envision that some tools are less complex and require less knowledge than others.

Next week, we plan on working with the sensor and nodeMCU once they arrive, as well as the Ethics assignment due Wednesday as a deliverable. Overall, we are slightly behind schedule, but plan to catch up during this week as soon as we receive our parts.

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.

This week, we started by meeting with Tamal and Alex about our new project idea. We decided to narrow down our scope to just monitor machines with dashboards (i.e. stationary bikes, treadmills, and stair climbers). From there, we began to work on our design. On Monday, the three of us looked at certain parts that we would use for our project. For example, Ian F. looked into which IR sensor he thought would be best, Ian B. looked into Django and the RPi that would be used, and Nat looked into the microcontrollers for the project. Later in the week, Nat and Ian F. worked on the block diagram for the Design Presentation, and Ian B. worked on a mock up for the web app.

The main principle of that we used to develop the design solution for this project is KISS, or Keep It Simple, Stupid. The idea with this principle is that we did not want to overcomplicate our design by adding unnecessary components. One example of this principle in action was when we thought we would need a battery to power our project, but Tamal mentioned using the charging ports already present on the machines.

One significant risk that could jeopardize the success of the project is not being able to detect whether or not a machine is in use with the IR sensor. This risk is being managed through testing the sensor at various ranges, and our worst-case scenario contingency plan would be to use an ultrasound sensor which would have more range.

No changes were made to the existing design of the system because this is the first iteration of the design.

 

Our proposal presentation for this week was not satisfactory for us and our project idea for RotoCam was not fully fleshed out. In addition, the idea seemed outside of each of our areas of expertise since none of us had prior experience with video processing tools or techniques. As a result, we agreed that the project was unsuitable for us and the risk of an incomplete minimum product was rather high. Therefore, our team has decided to change our project and pursue a different idea.

Our new idea centers around an occupancy tracking system for a gym. Specifically, we want to keep track of which machines are being used inside the gym and gather data in terms of occupancy throughout a given period. For this we were thinking of implementing a series of proximity sensors to detect whether a user is currently utilizing a specific machine and report this data via a web-app available for the gym members and the staff as well.