Category: Ian Brito’s Status Reports

This week, I mainly worked on finishing touches for the web app (UI/front end related tasks and small bug fixes). Overall, I would say work on the web app is complete. There was not much testing to be done individually on the web app that has not already been done: setting up a new machine works, admin page works, we tested time to update with various runs, which all worked.

Next week, we will work on all our deliverables, which include the poster, final report, final video, and final demo. I would say the main priority for this week is the final report due Friday, as it is the largest assignment of the bunch. Therefore, most of this week will be spent working on that.

Heading into the final week, I would say we are on schedule to wrap things up neatly.

This week (and last week, given there was no status report), I added a few key features to the web app. First, I made sure the register endpoint was fully functional — the register endpoint is the API that the nodeMCUs hit on start up to that they are assigned their IDs. Next, I worked on an admin page as discussed in our group meeting, so that admins can assign machines to IDs. This involved creating HTML for the page, working on JS, and backend login for Django so that only logged in admins can access the page. Thirdly, after discussing with the team and Alex, I realized my initial approach for average business for machine was wrong, and updated that. The new approach simply calculates % business (aka # machines busy/# total machines) and plots them per day.

Next week, the big overall goal is just cleaning up the CSS so that the page looks better. However, the first main focus is the final presentation next week. We have done some testing in terms of our use-case requirements (response time, accuracy, etc.), but have to finish our slides before tomorrow at midnight.

Overall, I would say that I am on schedule, and so is the rest of the team. Not much is left to do with the web app itself besides finishing touches and polishing before the demo, so the main focuses now are the deliverables in the coming weeks.

This week started off with the interim demo on Monday. From there, I continued work on the front-end of the web application this week. While the visuals for the web application were fine for the demo, I believe there was room for improvement. Next, one piece of feedback/one question that I was given during the demo was “How does each machine know which id it is?” The process for the demo was to have the nodeMCU send a POST request with its id preconfigured — but for setting up a new nodeMCU, this was tedious. Instead, I worked on the backend for registering a new device/machine. The nodeMCU sends a POST request to the web app and receives back its unique ID, which the web app also stores in a model. Overall, I would definitely agree this is a much more streamlined solution for registering new devices.

This coming week, I plan on fixing any bugs with existing code, as well as implementing the final functional feature, which is the average time spent on the machine.

In terms of schedule, I would say I am on track with the schedule posted for the interim demo, except for sockets (which we mentioned in the demo that POST requests might just suffice).

The tests that I have run and am planning on running are:

– testing adding new machines with the register api

– updating busy and free status for existing machines

– testing reporting a machine as broken

In particular, the second test is the most important because in order to meet our requirement, we need to ensure that updating the machine is accurate and quick.

As I stated in the last weekly report, this week was rather busy for me so most of my progress would be made on Friday through Sunday before the interim demo. Regardless, this week I managed to get AJAX working with JavaScript for the front end, so that the website automatically updates which machines are free and which are busy without the need to refresh the page. Furthermore, Nat and I were able to test that sending data from the nodeMCU via POST requests work, which was reassuring.

Next week, including tomorrow, my plan is to finish the work on the front end (mainly CSS), add a “Report machine broken” as Alex suggested, and work on sockets with Nat. Although we want sockets working for the interim demo, sending data via POST request is our fallback.

In terms of schedule, I would say I am on schedule. This week and next week were designated for working on the front end of the web app, since that would mainly be CSS and other visual things.

This week, I accomplished a few key things on my part. First, I purchased the domain for the website using Amazon Route 53. Then, I used Route 53 to get the domain to host the web app from the EC2 instance. Moreover, I worked on the POST request as described in the Design Report. Specifically, if a POST request is made with data as {‘id’ = 22, ‘status’ = ‘free’, ‘machine’=’bicycle’}, the web app can process that response by updating the pre-initialized Django model with these fields. In this case, it would look in the MySQL database for the machine with id == 22, and set status to  ‘free’. Overall, I think I made solid progress on the backend side of the software stack this week.

Next week, preparing for the interim demo will be the main priority. Unfortunately, I have two exams next week, so I will have to manage my time carefully, and a lot of my work will likely be done towards the end of next week and during lab sessions. The main priority for next week is now that I have the POST requests working and can update the models with whether they are free/busy, I want to work on updating the front-end with this information instead of dummy information that I am still using. To accomplish this, I should just need to loop through all the instances of my Equipment model and place them accordingly with HTML/CSS. Additionally, I need to work on the average time/business feature.

In terms of schedule, I would still say I am personally on track. These next two weeks were meant to be me working on the front end, which is what I am doing now.

This week, I worked on getting everything set up with EC2. Specifically, I worked on hosting the web app on EC2, configuring Apache with the Django web app, and setting up MySQL. I also worked on the web app itself a bit more in terms of visuals.

Next week, I will work on taking the data from the node MCU (since Nat was able to get POST requests to send data working) and using that for the web app instead of mock data. Additionally, I might consider looking into more secure ways to verify that the data is coming from the nodeMCU, as that was one of the feedback we got from the design report (the `key` in our JSON can be replicated).

I believe we are on schedule, at least for the software stack. The web app is successfully hosted and can be visited, and this week + next week were designated for receiving data from the nodeMCU and storing that for the web app.

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.

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.

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.