Posted on

Ian Brito’s Weekly Status Report for 3/25

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.

Posted on

Team Status Report for 3/18

This week our team primarily worked individually and made some good progress on the the three components of our design: the sensor module, the microcontroller and the software stack.

In terms of the sensor module, we were able to overcome the obstacle presented by our delayed order for parts and initial testing was done with the IR sensors that provided an overview of its behavior and validated that the sensors we were able to obtain were operational. We got a feel of how the sensor works and how to integrate it with the NodeMcu later on. Some results were unexpected but further more rigorous testing for next week should clarify this. In addition, first steps were taken to integrate our sensor to the NodeMcu by researching Arduino code and libraries that will prove useful in our application.

The majority of the progress this week was made on the communication protocol between the NodeMcu and the Software Stack. Nat worked on setting up the nodeMCU which we received this week, as well as formatting the POST request to send data to the web app.

For the Software stack, we were able to host the web app on the EC2 instance on an Apache web server configured to our liking. This means two things: 1) We are able to visit the web app outside of locahost and 2) we are able to send POST requests to the web app. Also, we set up the MySQL DB that will be used with the web application.

As a result, the top two priorities for next week will be to continue our development on the sensor module with the ultimate aim of interfacing the sensors with our NodeMcu, and refine the communication between the NodeMcu and the stack so we can then bring it all together in order to obtain a working and functioning system to be presented in a couple of weeks as part of our interim demo.

Posted on

Ian Brito’s Weekly Status Report for 3/18

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.

Posted on

Ian F’s Status Report For 3/18

This week was somewhat slow in terms of progress and unforeseen events caused some setbacks for me. As a result I am still behind schedule, although not as critically as past weeks. When it comes to deliverables for the week, some personal circumstances caused a delay in my ethics assignment, resulting in a 1 day late submission of my write-up. In addition, I was expecting the sensors to be available by this week. However, after consulting at the equipment desk, the staff informed me that the shipping was delayed and no updated delivery date was provided by the distributor. 

Despite this, I was able to get my hands on a few sensors by the end of the week and begin some informal testing to understand and observe their behavior. My aim with this lab session was to familiarize myself with the equipment and take some initial measurements that will guide more formal experiments next week. Thus, the main goal was to connect everything properly with analog components and merely determine if the sensors were operational.

Having said that, before connecting any components, I reread the documentation for our sensor. On it, the manufacturer suggests including a by-pass capacitor of 10μF or more between the input voltage (Vcc) and ground (GND) in order to stabilize the power supply line. As a result, I sketched the following circuit diagram and connected the components accordingly.

The DC voltage source was configured initially to 5V and an LED was connected in-between ground and Vo in order to measure the voltage outputted with the voltmeter shown and have visual cues of the sensors behavior. After firing up the circuit, I observed the LED dim as the distance from the sensor was altered. However, on the meter I saw some figures that were concerning. I compared the voltage drop across the LED to the following graph and numbers provided by the manufacturer.

Admittedly I used a rather crude form of measurement using stacked rulers, yet I observed that the sensor did not behave as depicted on the graph. Firstly I saw that the voltage drop across the LED was never higher than 2V. Secondly the output was off by a few centimeters. For instance, I had expected to observe upwards of 2.5V around 16cm yet the peak voltage was observed closer than that at around 11cm and it was still no larger than 2V. I also noticed that the sensors behavior at very close distances is not as expected. since the LED was still on and the voltage was high despite the object being less than 5cm from the sensor. At large distances the sensor started to behave as expected fluctuating between 0.5 to 0.7V. However, it was quite jittery. I also proceeded to toggle the input voltage based the operating range of the sensor (4.5V – 5.5V), yet this did not seem to have any effect on the output which is a behavior that is beneficial in our case. ( I performed most tests at 4.8V since this is the voltage we expect from our battery supply later in the future when we make the sensor module mobile.)

As mentioned all these results were informally recorded. The unexpected behavior is most likely caused by the properties of the LED and my thoughts are that these measurements will be more true to what the manufacturer suggests when the NodeMcu is integrated and connected to our sensor. So for next week, I will test things more meticulously and properly record the data from these experiments. I will try some things out at the analog level to see if the behavior described above changes. For instance, I intend to use a circuit configuration that is not dependent on the LED. I will also employ a measuring tape to obtain more accurate distance readings. In addition, I want to see if changing the power supply line capacitance has any effects on the output voltage (which I think not) and perhaps figure out if there is a ways to reduce the jittery behavior at long distances so that we can feed a better voltage to our NodeMcu.

Speaking of NodeMcu, I set up the Arduino IDE and performed some basic tests to familiarize myself with the component and its behavior. I followed an online tutorial to setup the IDE with the NodeMCU and successfully ran a simple program suggested in said tutorial that blinked an LED every second.

Thus for next week, after finishing my tests with the sensor, I will proceed to develop a script for the NodeMcu that will display the distance measured by the sensor connected to it. I will compare and contrast these results with the analog measurements as well as the graph from the datasheet and see how we can fine tune the measuring portion of our project or if an entirely different sensor or approach is necessary (which we estimate is highly unlikely).

Posted on

Nat Arocho’s Weekly Status Report for 3/18

This week was critical for getting work done for our project. While I wish I could have spent more time working on our individual tasks in the project, a good amount of time was spent working on the Ethics assignment. Despite this I personally made a lot of progress on my end. I wrote up code to be ran on the NodeMCU; This code is responsible for sending a POST request to the web server, this will be our main form of sending data from the NodeMCU to the web server. I used this tutorial (https://randomnerdtutorials.com/esp8266-nodemcu-http-get-post-arduino/) to assist me in designing the code.

I would say our progress in currently on schedule. I still need to test the NodeMCU code with the web server, but I plan on doing this Saturday when our team meets to complete step 3 of the ethics assignment.

Next week it is critical that we spend some time out during the week working during the project, as we our missing one class for the Ethics lecture. Meeting Saturday will mitigate some of this work but it is important we stay on schedule so development isn’t hindered too much.

Posted on

Team Status Report for 3/11

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.

Posted on

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.

Posted on

Ian F’s Status Report for 3/11

For the week before the break, no progress was made on my work with the sensors and the design report turned out quite poorly and unsatisfactory. As a result, I am behind the projected schedule. Therefore, next week will be critical and significant work must be done in order to catch up and deliver on our product.

The first order of business, will be to pick up our sensors from the ECE equipment desk and start the local testing right away so we can have metrics and data to feed to our NodeMcu as well as understand the behavior of the sensor in order to fine tune it with our microcontroller. Once we have the sensor up and running, we will have a few main variables that will guide our experimentation. These are: distance from the sensor, fabrics/textiles and colors used for detection as well as the angle from the sensor (both vertically and horizontally) at which we place our subject.

In addition, the data gathered from these trials will also inform our power consumption estimates and based on this we will modify the plans we outlined on the design report or simply go ahead approve the batteries we intended to use as appropriate and proceed to order them.

However, prior to starting the testing at the beginning of the week, I must carefully review the design specs of the sensors and draw sketches of simple electrical circuits depicting the configuration that will be used for testing as well as the one that involves our NodeMcu. Careful consideration must be taken when connecting these components since we do not want to damage or ruin the equipment we have. After the trials are completed, I will work closely with Nat to integrate the sensor and the NodeMcu in order to have a working module that can then be scaled to the quantity we are aiming for.

Once we have the sensor and NodeMcu running, as part of my contribution for this subsystem, my focus will shift to the mounting mechanism that will be used to place our sensor module on the selected gym equipment. As a result,  I will have to brush up on my knowledge of fabrication techniques and simple prototyping. For the encasing that will house our module I must analyze which method of fabrication like 3D printing, manual woodwork, among others, is best . If we decide to go the 3D printing route, this will require familiarity with CAD tools and other similar suites available in the Makerspace, as well as careful scheduling and planning to reduce the time wasted while we fabricate encasing prototypes. If we deem this to be inefficient or too complicated for the purposes of our project, then I will explore simpler and perhaps even cruder methods of fabrication.  However, we must keep in mind our requirements of stability and robustness to vibration of our module when making this decision. Thus, we will most likely choose a fabrication method and tools that provide a balance between sophistication and ease of implementation and use. We want our module to be strong and rigid but we also want a tool that is simple to use given that we need to make the most out of the time we have and we need to catch up and keep up with the schedule.

 

 

Posted on

Nat Arocho’s Weekly Status Report for 3/11

This week was mostly spent working on the Design Report. This assignment ended up being a much larger task than our team anticipated for; As such most of our time this week was spent working on said Design Report. I also planned on starting the NodeMCU development, however since the parts arrived very late into the week I was unable to start development before the start of Spring Break.

I would say my progress is currently still behind schedule. The NodeMCU arriving so late into the week definitely contributed to this, as did the Design Report taking a significant amount of our time.

Next week it is critical that development for the NodeMCU begins, getting a simple prototype working shouldn’t take too long, after that is completed I will immediately get to work on developing the code to be used in our system.

After establishing our set of sub-systems for our design report, we realized using a Raspberry Pi to host our web server may not be ideal for our project. To account for this we shifted our project to use an EC2 Instance instead of a Raspberry Pi.

Posted on

Nat Arocho’s (Slightly Late) Status Report for 2/25

This week was a bit slower compared to other weeks in the course so far. The only big deliverable that we had to have completed for this week was our Design Presentation, which I think went quite well. I also planned on spending some time this week ordering the NodeMCU so I can get development started with that.

I would say my progress currently is a little behind schedule. This week was quite busy for me; I spent most of my time this week doing work for the classes that are important to me. Due to that I did not order the NodeMCU during the week, however the good news is I ordered it as I am typing this report.

Next week I plan on working on a simple NodeMCU prototype to understand developing for the device; I plan on getting this done before Spring Break. If the NodeMCU does not arrive before then that fine too, as I’m sure I can spend some time during break working on the project to stay on schedule.

Recreating our schedule last week was critical, this allowed us to counter the design challenges associated with changing projects weeks into the course.