Posted on

Nat Arocho’s Weekly Status Report for 3/25

This week was spent refining the NodeMCU code written last week, as well as testing the code with the web server. It would have been nice to have two days of lab to work on the project; its a shame our Wednesday had to be spent at the riveting ethics lecture.

I would say our progress is still on schedule, maybe slightly behind. I currently don’t have access to my ADHD medications due to the shortage so work is a lot harder to complete now, hopefully next week will be less frustrating.

Next week it is critical we spend time working on this project so we can make sufficient progress in time for the interim demo. Hopefully I get access to my medication sometime in the coming week; Doing work without them is near impossible for me.

Posted on

Team Status Report for 3/25

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.

Posted on

Ian F’s Status Report for 3/25

Last week’s scheduled testing did not take place. In consequence, I believe I am behind schedule but this is not something that will have significant or negative repercussions down the line. I believe that next week I can catch up and develop this subsystem further in order to meet the requirements and the expectations for the interim demo on the first week of April.

Having said this, some progress was made on the code side of things with the NodeMcu and the sensor. I worked on two versions of an Arduino script for the NodeMcu which takes in the voltage outputted from our sensor and performs the necessary calculations based on the graph on the sensors datasheet. I have not tested the script with the sensor directly. As a result, the plan for next week is to complete the testing mentioned last week and download the script onto the NodeMcu and see if it requires modifications or any other refinements. My hope is that with this script we are able to obtain digital distance measurements that can be compared with the analog ones obtained from our lab equipment. This way we can see if our script needs work or if it provides better results than the analog testing.

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.