Ian Brito’s Weekly Status Report for 3/11

This week, most of the time was spent doing the Design Report and discussing ways to improve our design. After receiving feedback from the Design Presentation, we realized that we did not have strong justification for using an RPi to host the web app. We changed this to hosting on an EC2 instance, as it is something I have prior experience in from web app course.

Next week, the plan is to work on the Ethics assignment as well as hopefully receive the NodeMCU so we can start communication between the web app and the sensor module.

Given that we once again updated our schedule to accommodate the change from RPi to EC2 hosting, I would say that we are still on schedule. I created the EC2 instance running Ubuntu 20.04 and have the web app prototype working with some design touch-ups needing to be made with React.

The new tools that we have determined to be necessary to accomplish the tasks, as mentioned, is AWS and EC2 instead of the RPi. As mentioned in the Design Report, EC2 is more secure and provides a consistent uptime as opposed to a RPi.

Ian Brito’s Weekly Status Report for 2/25

At the beginning of this week, I presented our design presentation. For the rest of this week, most of the work was ordering my part (RPi) from ECE inventory and working on the web app. I created the Django web app, but do not yet have it looking like the mock up. Additionally, I looked at the Design Report to start thinking about what to write in it.

I would say that currently, my progress in on schedule based on the new schedule from the design presentation which we updated after we pivoted our project. We had planned for most of this week to be ordering parts, starting work on web app (me), and generally working on the project idea. After receiving feedback on Friday, I thought of ways we could increase the scope of our project, such as adding more sensors or adding complexity to the web app.

The deliverables that I am looking to get done next week are the Design Report, as well as getting the web app running on the RPi. I want to get both of these tasks done before Spring Break so that our group is on schedule.

We have adjusted team work assignments to fill in gaps by recreating our schedule as stated above to account for the late(ish) pivot in our project. Because our schedule was created fairly recently (last week), we were able to plan accordingly.

Team Status Report for 2/18

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.

 

Ian Brito’s Weekly Status Report for 2/18

During this week, I went back and answered some questions from the proposal document for our new project. For example, I wrote a use-case, requirements, technical challenges, etc. in a document as I believed that this information would still be useful for our group going forward with this project. Additionally, I created a mock-up for the Django web application, as seen on the Design Presentation slides. The reasons I chose Django for creating the web app as opposed to another framework are that it is secure (provides protection against certain attacks) and versatile, which makes it the perfect framework for this project.

I would still say our progress is slightly behind schedule. Because we had to restart our project, I feel as if we could have been farther ahead — however, our new schedule as shown on our slides accounts for this.

The deliverables that I hope to complete in the next week are the Design Report and beginning work on the web app itself.

The particular course that helped in my portion of the design was 17-437, or Web Application Development. This course covered Django web apps and web app development, which is the framework I am using to create the web app for this project.

Ian Brito’s Weekly Status Report – 2/11

Our team decided to pivot our project idea on Monday (2/6) after meeting with Tamal. We believed that given our inexperience with video and image processing, RotoCam would not be a feasible project for this course. Instead, we decided to pivot to an occupancy project similar to those done in the past. Our project would focus on the UC Gym and report which equipment is currently being used to a web app.

For the second half of this week (once we all agreed on our new project idea), I began looking into how I would implement my portion of the project (the web app). I settled on a Django web app, which would be hosted on a RPi that would communicate with the micro controllers to determine which equipment was being used. I have previous experience with Django and I believe it would suit our needs for this part of the project.