Author: rgess

This week I worked on our final presentation and sent out our survey to my peers to begin collecting data on user experience preferences and data on privacy concerns.

I also worked with the group on more testing and adjusting of our weights. As we get more survey responses in, we will use those to guide our final weights. Our goal for this week is to do more testing, finish up our in person demo and create our final video as well as write the final report.

At this point in the project, I am proud of what we were able to accomplish this semester and we are in a good position to finish things up before the final demo.

This week I worked on testing, refactoring our code to allow for faster testing and verification, and drafting a user survey to guide some of our design decisions. In addition, I soldered and created another “base station.”

(User Survey: https://docs.google.com/forms/d/1YM4OFE08eWwsJJnDHzXr_HDfEiTtsAuOjxWQ_ADB7e0/edit)

The testing I completed involved our first requirement: to turn on the lights within 2 seconds of a person entering a section. This ensures our computation and communication latency from signal detection to computation to signaling the lights is fast enough for our user. In order to capture times, I recorded myself on video, and timed from first movement to the lights turning on for five trials. I obtained the following results. The average time is 1.028s and each trial is below 2s.

Trial,Time
1,   1.2s
2,   0.81s
3,   1.11s
4,   0.97s
5,   1.05s

To assist with further testing, I refactored our code and began developing a script to modify and adjust our weights given values captured and written to a test file along with a desired light behavior. The script uses a gradient descent-like algorithm for adjusting weights and validating defined test cases. Weights will be slightly modified until (hopefully) the desired light behavior is correct for all test cases.

This coming week I will continue testing, send out the survey to collect responses after it is finalized and create another base station.

This week I worked to solder and set up another base station with a pir sensor and microphone and work with Diva and Malavika to get messages sent from our webapp to the Rasberry Pi base station in addition to doing some initial testing with two base stations.

I tested by doing some work and moving around .5m from one base station and also 1m from that base station. This allows us to observe the sensor values when a person is in our defined work station and also when the person is outside of the defined work station. I wrote the values to text files to allow for backtesting and allow us to tweak our weights with immediate feedback on accuracy. For the most part, our data looks promising, we are getting a lot more feedback from the station I am closest too however there is some noise from both sensors (false positives) so we’ll have to decide how we’d like to handle this in order to maintain our turn on latency.

This week my focus will be to add one more workstation and do some more testing so that I can work with Diva to optimize our weighting.

This week I worked on integrating communication between our sensors and Raspberry Pi to the logic Diva is working on and assist Malavika in tying in the web app as well.  The integration with Diva is mostly complete while the integration with Malavika will require some more work, we ran into some bugs but mainly were focused on a proof of concept and verifying that we can in fact send messages from the web app to the Pi which we have verified.

I worked to solder and set up two stations for our interim demo. Each station consists of a ESP8266 (WiFi) microcontroller, a microphone, and a PIR sensor. I programmed the ESP8266 microcontroller to send the sensor data only when it changes. The idea behind this is for improving latency. The amount of messages sent from all the microcontrollers is reduced and the logic is distributed to these microcontrollers preventing constant checking in our threads. In addition, no information is lost because we can assume the value is the same until it changes.

Here is one of the work stations with our ESP8266 connected to PIR and microphone sensor.

This console output shows the result of some initial testing with full integration for 90 seconds. In the first output, we were closer to workstation0 and our algorithm computed a score of 133 whereas workstation1 had a score of 87.  Next we tested the reverse and got scores of 79 and 140. We still need to test and adjust thresholds however it is very promising to see higher values corresponding to the workstation we were closer to.

This was a productive week and we seem to be close to our original schedule. This upcoming week, I plan to set up more work stations (increasing from 2 to 4). In addition, I will work to integrate more functionality from the web app that Malavika is working on. This will involve including more logic for the messages that will be sent from the web app in addition to the logic for sending messages from the Pi to the ESP8266 microcontrollers.

This week I worked with Diva to to verify we can receive input data from two different microcontrollers connected to different sensors. We were successfully able to collect data with a microphone sensor and send it over our communication channel to our raspberry pi. (See Diva’s report for a photo).

I also worked on testing the limitations of our communication system as Professor Tamal brought to my attention that the networking capabilities of a Raspberry Pi are fairly weak. We are able to receive messages when the microcontroller is placed in any part of the room however once I had more than 2 sensors things break down and we cannot receive any messages. Below is some data I collected with two sensors, the mac address is the unique identifier and I also collected the signal and timestamp.

 

I used this blog http://www.steves-internet-guide.com/multiple-client-connections-python-mqtt/ to try to work through some of these communication issues and try a different approach to what I am currently doing. I still need to perform more research as I haven’t found many others experiencing this issue online. This week I plan to look into this some more as well as possibly investigate a different protocol however this would not be ideal as it seems MQTT can integrate nicely with our web app.

This week I focused on our ethics assignment and setting up our communication. The exercise on ethics was helpful and we received a lot of good feedback on our project about issues that we hadn’t considered before. Specifically, knowing the location of people in a room can give an adversary ability to do more harm.

Setting up our devices on CMU-DEVICE wifi proved to be a little more challenging than expected. This set us a little behind schedule but I think we are still on track as this week I successfully registered and connected all of our ESP8266 microcontrollers to CMU-DEVICE as well as the Raspberry Pi. This will help with testing as we won’t need to wire our entire system together. Now that these are setup, we can focus on setting these up with our sensors so we can do more exhaustive testing.

This site https://vimalb.github.io/IoT-ESP8266-Starter/ was particularly helpful in connecting ESP8266 to wifi and learning Mosquitto (communication protocol for IoT applications). Essentially it works by setting up our Raspberry Pi as a MQTT broker and publish messages to it from our sensor microcontrollers. Messages require a topic and a payload and each have a unique client identifier so we know which controller / sensor our message is coming from.

This week I focused on editing the slides for our design review presentation and preparing to present. I also began working with my team on our design review report. In addition, I worked on setting up the Node MCU for wifi communication. 

This week I plan to continue working on the Design Review writeup and do some meaningful research in my focus areas to flush out our design review and implementation details. 

This week I spent quite a bit of time researching various techniques for tracking multiple humans in a room using IR sensors. There are a few proposed algorithms for tracking paths of people in a room and distinguishing between multiple individuals. I worked to order these algorithms so that  when our parts arrive I can start testing as soon as possible. I also looked into some videos on how to set these up and coming up with and researching simple heuristic techniques for human tracking.

We are still early in the project but we seem to be on schedule. We are hoping to get our parts in soon (we submitted our order this past week) so that we can start testing. 

This coming week I plan to continue researching setup and tracking algorithms and possibly begin to play around with a few heuristical approaches provided that our sensors get in soon. 

This week, I worked with my team to further brainstorm our requirements, and decide which items we would like to order. I have been working on our proposal slides and researching technological limitations and challenges we may face, regarding the localization using a combination of sound and motion detection. We’ve also discussed our division of work and schedule.