Posted on

Diva-Oriane Marty Status Report 11/6/2021

This week I worked on integrating the sensor values into the code I wrote last week.

As a group we debugged getting messages sent from the web app to the raspberry pi using mosquitto protocol. After testing the microphones we decided on using the one with a potentiometer that controls the “sound” threshold and output a digital signal. It seems sensitive enough for our test case and provides the most reliable data. It also allows us to insure anonymity and privacy. We are currently able to send appropriate sensor data to a LED on the board that represents a base station.

For the interim demo: I have a working station that sends signals to the raspberry pi and for which the raspberry pi behave accordingly. I almost have the sensor data being sent directly from a microcontroller to the raspberry pi, but I hope to finalize that tomorrow (Sunday) before the demos on Monday. Next week I hope for us to be able to scale up to at least two base stations, start placing the various sensors around the room, and more elaborately incorporating the options from the web app.

Posted on

Malavika Status Report 11/6/21

Continuing from last week’s status report, this week entailed presenting the use cases for the website as well as the layout for the graphical controls interface users can interact with in order to control the lights as well as the sensors in the system. I showed Professor Yu and our TA the vision I had in mind which includes four separate switches on the webserver which can turn each of the four light switches on or off. The controls page will also contain a switch to override the automatic weighting of the PIR and microphone sensors and allows users to turn a knob and specify the relative weights of the sensors when deciding to turn on or off a light.

Professor Yu suggested that when the webserver is not overriding the Raspberry Pi, users should be able to view what the control weight settings currently are in automatic mode to allow them to make a more informed decision when manually setting the sensor weights.

I also established in our weekly meeting that there will be a bidirectional communication channel between the webserver and the Raspberry Pi, which serves as the broker in the Mosquitto communication protocol our system uses.

The rest of the week I was going through the MQTT tutorial to interact from the web server to the Raspberry Pi. I established that the next immediate step was to communicate to the Raspberry Pi, and worry about the other direction later. I got the dummy website I was building through the tutorial to connect with the Raspberry Pi after debugging with Ryan, Diva, and Professor Mukherjee (see images below). While the webserver can establish a connection with the Pi through the websockets protocol on a specific port and subscribe to the pir/data topic, it is unable to actually send messages, which I will debug after the demo. As of now, it is simply a matter of transferring the functionality from the dummy server to the controls user interface on the actual website and editing the current JavaScript to support this action.

For the demo, I will display the website and graphical interface itself as well as its ability to connect to the Raspberry Pi.

Posted on

Ryan Gess Status Report 10/30

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.

Posted on

Malavika Status Report 10/30/21

This week I was able to run the source code following the tutorial I found online to allow a user to ultimately control the PIR sensors and microphones. The website contains JavaScript that controls the 4 LED lights on the breadboard which is triggered by events such as a mouse click on the appropriate button or sliding the toggle button. The webserver is started on the Raspberry Pi terminal using node js and is run locally, which allows users to visit the webserver on any device by going visiting the ip address of the Pi on which it is running. Web sockets are also used to establish a connection to the client’s browser which allows the server to then send appropriate data to the specified GPIO pins. At the moment, the GPIO pins are controlling LED pins (as illustrated in the image below) but our final project will entail the LED strips being connected directly to the GPIO pins on the Raspberry Pi.

During our weekly meeting with Professor Yu and our TA, I received feedback saying the webserver portion of the project needs to be better motivated and justified. Currently, the scope of the webserver is just to allow users remote control access to the LED grid. However, in order to address this, I decided to incorporate a feature that will allow users to determine the weight of each sensor (microphone vs PIR) when the Raspberry Pi is deciding which thread count to decrement according to the presence of sensor data.

At the moment I am just incorporating buttons that allows users to specify to the central Hub to ignore data from microphones or PIR sensors. This will be done by using the MQTT protocol. The webserver will instantiate MQTT messages whenever buttons to toggle sensor weights (and turning on the light) are pressed and publish this to the destination of the communicate.py code running on the Raspberry Pi. The central code can then check for which messages are incoming using cases and send a signal to the appropriate thread in control of the LED grid section.

We plan on implementing this using a block signal (sent from the webserver in the event of a button click to turn an LED on) that the central communication code will place onto a queue of messages for the thread to process. If this block signal is seen by the thread, it will stop decrementing the counter for the light switch which turns off when the count is set to 0. Likewise, an unblock signal will be sent if the user turns off the button for the lightswitch which will eventually signal the thread to start decrementing again.

Posted on

Diva-Oriane Marty Status Report 10/30/2021

This week Ryan and I worked on testing receiving input data from two different microcontrollers connected to different sensors. In the picture below you will see the two microcontrollers both sending data being received from two opposite facing PIR sensors. Next week, we need to make sure that the IDs of the microcontrollers are recognized by the base station.

I worked on looking for new microphones and ordering them. We ordered three types of microphones. Amongst these microphones, we have another copy of the previous type microphone in case the lack of signal (even after soldering) was due to a defect.  We will test them early next week.

I also worked on writing a threading script in python that works with simulated sensor data. Based on incoming sensor values, the thread corresponding to a work station modifies the work station’s score.

I implemented this in code:

The code is here

The code works, but the score values are random, so next week I want figure out a logic behind the score constants and timeout constants. I also want to have some idea of potential microphone thresholds from the new microphones we have ordered. In addition, I want to talk  through the web app with Malavika to figure out what other inputs the base station’s code needs to account for.

Posted on

Ryan Gess Status Report 10/23

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.

Posted on

Malavika Status Report 10/23/21

This I made progress on the templates and static files for our website (as pictured below) as well the ethics assignment we had. For the ethics assignment, we read two articles, one by a historian, and the other by the ethics guest lecturer we saw in class in Wednesday that highlighted how we should think about the design decisions we make as engineers and how it affects the community in which it exists. We got to consult with other teams on the use case and possible vulnerabilities of our project, and received valuable feedback on how to improve our system to be more ethical and secure.

I also designed the login, register, and main page of the website on which each zone of the LED will be controlled. Using django and OAuth, I implemented the login feature which allows authenticates already existing users using their username and password which is stored in a sqlite database. New users that want to make an account on the Lights Out webapp and connect to their in home device can register a profile on the register page (I still need to use forms to implement this).

Posted on

Diva-Oriane Marty Status Report 10/23/2021

This week in class we were focused on the ethics assignments. Outside of class I worked on microphone testing with our adafruit SPW2430. The preliminary testing is hopeful, but I was unable to get a working soldering machine, so the connection is not very accurate, so hopefully after soldering we will get even better results. The microcontrollers and raspberry pi have been registered with the cmu wifi, but we are still working out some connection issues. This step is necessary before we try to combine the two types of data.  The tests were run with an arduino in order to have an analog port to test with. The wifi microcontroller have analog ports, but for inital testing it is not necessary to run it over wifi.     This is an example of the results from one of the tests:

The tests account for the DC voltage bias. We had hope to be connected our different sensor data this week, but we are not too far off from our expected timeline.

Posted on

Diva-Oriane Marty Status Report 10/16/2021

This week I primarily worked on the Introduction, Design Requirements, Architectural Overview and System Description of the design report. I spend the majority of the time thinking through the Software Design of our system and the interfacing between the sensors and the software. 

I also helped with the testing of the PIR sensors during lab.

Next week I plan to work on a lot on testing, and particularly focusing on the microphones, to determine false positives, reasonable thresholds, etc. I hope to also start combining the data from the PIR sensors with the microphone in some preliminary tests.

Posted on

Malavika Status Report 10/9/21

This week I did more research into how to have the web server interface with the GPIO pins on the Raspberry Pi. I found a well documented tutorial on how to implement this using Node.js and web sockets. I also began working on the design report after we divided the report between ourselves.