Ian Brito’s Weekly Status Report for 4/8

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.

Ian F’s Status Report for 4/8

This week significant progress was made on the sensor module compared to other weeks. First off, I decided to formalize the testing I described in previous reports integrating the NodeMcu with the IR sensor. For this testing, I set up my circuitry as depicted below:

The IR Sensor was powered by a lab power supply set at 4.8V and the NodeMcu was powered directly from my computer via MicroUSB. As you can see I decided to attach a voltmeter in between the output voltage of the sensor coming into the analog A0 port of the NodeMcu and ground in order to measure the voltage going into the NodeMcu. Following my research into the Arduino IDE and the NodeMcu capabilities, I discovered that the analog voltage coming in can be read by the native analogRead() function that has a 10-bit resolution measurement capability courtesy of its analog to digital converter. Rather than outputting the voltage measured directly like a voltmeter would, the function outputs an integer reading that is mapped and correlated to the voltage and  ranges from 0-1023. With this in mind I developed the following simple script in order to determine the correlation between the voltage measured by the voltmeter and the digital reading outputted by the analogRead() function:

With the script set and uploaded to the NodeMcu, I placed the sensor near the edge of the table and used a measuring tape (in inches) in order to observe how the voltage and the digital reading changed based on the distance I stood from the sensor.

With this setup in place I utilized the serial monitor and the serial plotter from the Arduino IDE in order to sample and record the digital output of the sricpt, and note by hand the voltage I saw on the voltmeter in front of me. I compiled the data and produced the following table and graphs:

I recorded Low and High voltages and ADC readings respectively since the measurement was not exactly smooth. Therefore, I noted the highest and lowest voltages measured by the meter and the peaks and valleys in the serial plotter corresponding to the ADC reading. In addition to relating the distance with the output voltage and the ADC readings, I related the ADC readings with the voltage and produced the following plots from our data table: 

As expected, the measurements were more accurate than the ones obtained in the informal purely analog testing described a few weeks back using the LED setup. The shape of the curves also met our expectations and resembles the one provided by the sensor manufacturer. Having said that, our plots are not exact reflections of the manufacturer graph, but close enough for the purposes of our implementation. I do recognize that there are some errors that come from the experimental setup and human measurements. Thus, the plot discrepancy could be attributed to our testing methodology. Nonetheless, the testing was conducted methodically and as carefully as possible. Thus I was confident that this data would serve as the basis for our algorithm development.

With this data in mind , I was able to create an Arduino Script for the NodeMcu that used the ADC readings to calculate the distance from the IR sensor in inches. This script was developed with the intention of using the calculated distance as the metric that would determine whether or not occupancy data would be sent by the NodeMcu. However, after some testing, I realized my algorithm and my script were not as precise near boundary distances of detection like 3.5ft as established by our design requirements. In other words, this was not sufficient to meet our detection accuracy since it was imprecise in situations where we needed it to be precise.

As a result, I looked at the data once again and utilized the relatively linear relationship between ADC and voltage in order to produce a simpler yet more accurate script. I also modified the circuitry and added an LED connected in between the D4 port and GND that would reflect the behavior of the sensor. The red LED would turn on when the distance was above 3.5ft and off when the distance was less than that.  The blue LED embedded in the NodeMcu would do the opposite.

This algorithm produced better results near the 3.5ft boundary. I also tried to test different detection angles and the sensor did not detect at big angles from the center line if none at all. The sensor pretty much worked in a straight line, which is good news for us.

With this phase of testing complete, I shifted my focus to making the sensor module mobile by incorporating the batteries from our design report. At first, I hooked everything up to the power supply but then proceed to use batteries instead. Regardless, the circuit configuration was the following:

I was able to get everything working both with the DC power supply and the battery pack, effectively creating a fully functioning and mobile sensor module, albeit without Wi-Fi capabilities just yet.

In addition, I measured the output voltage produced by the pack which turned out to be 5.4V (fully charged pack) (higher than the expected 4.8V). In addition, each cell is rated with 2,800mAh which brings the grand total to 11,200mAh. With this in mind, I decided to measure the current drawn by the sensor and NodeMcu individually, while detecting something in the desired range and while not. The NodeMcu registered a peak of 59mA while detecting and a low of 25mA while not detecting. On the other hand, the IR sensor readings from the multimeter unstably fluctuated to the point that no set measurement could be made. Nonetheless it did not surpass the 30mA mark that we had expected based on our research for the design report. Further power consumption studies need to be made with a fully Wi-Fi transmitting module, yet, based on our worse predictions of peak consumption, we estimate that we will meet the battery life requirement of 16.5 hours and perhaps surpass it. I was also employing a battery pack with a switch that could greatly extend our battery life. However, further testing will determine which pack is necessary and will be chosen for the module (static or switch enabled pack).

Aside from this, I started preliminary work on the fabrication of the senor encasing using Solidworks. Yet a possible implementation using AutoCAD, laser cutters, and acrylic plastic could be a solution as well.

In consequence, for next week my plan is to integrate the sensor and NodeMcu to transmit occupancy data with my teammates and then proceed to study the power consumption. Afterwards, I will shift my focus to the encasing and the mounting mechanism. I must acknowledge it is a tight schedule due to my limited knowledge of AutoCAD and Solidworks, yet I and the team in general is on pace according to the revised Gantt chart and schedule posted on 4/3.

Team Status Report for 4/1

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.

Ian Brito’s Weekly Status Report for 4/1

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.

Nat Arocho’s Weekly Status Report for 4/1

This week was spent getting the NodeMCU to communicate with the web server by sending a JSON via a POST Request. We successfully got this working earlier today; The work on my end accomplished was: registering the NodeMCU’s MAC Address on CMU-DEVICE so it can communicate with our webserver (this required writing simple arduino code to get the NodeMCU’s MAC Address), in addition to finalizing the code that sends the POST request to the webserver.

I would say our progress in on schedule for the interim demo; Our team will meet tomorrow to finalize our progress for the interim demo, we will also look into implementing communication via sockets for the interim demo. Overall I am confident in our team’s ability to be ready to present on Monday.

Next week will be spent improving our current framework from the interim demo. If the IR Sensor has not yet been integrated into the project by the time of the demo we will start work on that next week.

Ian F’s Status Report for 4/1

This week I missed a couple of sessions due to illness and therefore some progress was made but not significant enough to fulfill the schedule I had planned for this past week.

Regardless, I decided to perform some tests directly interfacing the NodeMcu with the IR sensor utilizing the simple Arduino script mentioned in last week’s report to perform simple analog reads and observe the voltage displayed in the serial monitor of the Arduino IDE. After interfacing them together, I noticed my measurements were quite inaccurate and inconclusive. After a while, I realized that the problem was the sensor since it was not properly communicating with the NodeMcu. I discovered this after I turned off the power source to the sensor and the readings were still confusing and exactly the same as when the sensor was powered on. I tinkered with the Arduino script and revised my connections yet the results remained the same.

In light of this, I replicated the analog setup detailed in the status report for 3/18 to see if analog measurements were recorded as expected and observed during those past trials. However, no readings were obtained and no voltage drop was observed across the LED (it also did not turn on). As a result, I need to review my wiring to see if that’s the problem or try out a different sensor since the one I was using might be non-functional (which is what I’m inclined to believe).

Thus, the plan for the weekend and the beginning of the week is to get a fresh analog setup with new components up and running and then set the connections with the NodeMcu in order to properly test the Arduino script. The goal is to have this subsystem running by the interim demo and and then merge my sensor script with the other communication script that handles the data transmission portion of the overall system.