This week we showed our final demo which included our MVP product that showed a user’s wearable device turn on with a light whenever it was their turn to do a task and the button which would rotate the task order for when someone finished …
This week we worked on building our final product from our MVP. I traveled back to home (Florida) from Pittsburgh, but I was able to access the Raspberry Pi remotely to work on the integration. I was in charge of getting our location detection working. …
This week I continued to try to get our MVP working. I started making the hub code more robust and continued to debug the message passing interface between the hub, wearable device, and the button. I also started to finalize our location detection method with using bilateration. To get bilateration set up the camera must also emit a Wi-Fi signal so I worked with David a bit to help him get a Wi-Fi breakout board attached to the Pi zero, so that the wearable device will be able to send the location of the hub and camera to the hub. This would allow me to determine the location of the device to a decent degree. Next week though our MVP should be finished up and ready to be demoed.
This week we made a push to get all of the major components of our MVP ready. We wanted to have the hub server be able to take connections from both a wearable device and a button. Since our MVP did not require the integration …
This week we decided to get our MVP up and running. I spent some time doing debugging work with David by having him constantly send messages to the hub, so I can interpret them and send messages back to the wearable device telling the device …
This week I did more research into our trilateration method and how we were going to get it to work. After writing up ways of how our trilateration would work, I realized a major flaw in our design. The trilateration design that people have implemented in papers depend on having stable known wireless access points to read from. Within a house there are stable wireless access points to read from but the distance to them is unknown and would require an enormous amount of setup time to find those values out. So, with that in mind, I managed to quickly find another approach to find out location that would suit our needs. For our device, we really just want to know if a person is within some region. So I planned out a technique that uses two wireless access points between a region we want to check if a person enters. This happens to be our hub and our camera. If the wearable device sends its location to the hub and its distances from both the camera and hub are within some threshold, we can determine that the person had entered that defined region attributing any mess caused to them.
This week I wrote a wifi scan program for the hub to survey the area for wireless access points, so we can use those rssi values for our trilateration calculations. I also added a task scheduler to the main hub program. To save the task …
This week I worked on parsing location messages from the wearable device. The wearable device encodes messages slightly different than messages sent by another pi, because messages from the wearable devices are all sent using raw bytes rather than a string converted to bytes. I …
During the start of the week, I worked on the math behind the accuracy of our Wi-Fi positioning method so that we can put it in our design report. I was actually sick for the first half of the week so I didn’t get as much work done as I would have liked, since I also had to make up work from a lot of other classes. But I continued the making the hub server multithreaded so I can handle the communication between multiple clients at once.
This week we finished doing some research to write our design report. Our camera is now able to receive input to the Raspberry Pi Zero. The hub can now handle multiple clients at a time and recognize which type of device the client is. We …